Вышла новая версия VMware Cloud Foundation 9.1, об этом вы уже знаете. В этой статье рассматриваются многие новые возможности и улучшения платформы vSphere в составе пакета VCF 9.1. Также рекомендуем ознакомиться с примечаниями к выпуску и уведомлениями о поддержке продуктов для получения важной информации.

Быстрое развёртывание патчей безопасности vCenter

Функция быстрого патчинга vCenter (vCenter Quick Patch) обеспечивает оперативное применение обновлений с минимальным, а в ряде случаев — нулевым временем простоя. Уровень простоя зависит от того, какие именно сервисы подвергаются обновлению. Механизм Quick Patch ориентирован на быстрое устранение критических уязвимостей безопасности в vCenter.

Традиционный in-place патчинг обновляет все RPM-пакеты на vCenter вне зависимости от того, изменился ли соответствующий сервис или компонент. Quick Patch затрагивает только те RPM или бинарные файлы, которые действительно изменились в составе патча. Такой подход кардинально сокращает общее окно обслуживания и снижает время простоя vCenter до менее чем 1 минуты, а в ряде случаев сводит его к нулю.

Благодаря vCenter Quick Patch критически важные обновления безопасности можно применять без прерывания рабочих процессов: развёртывание виртуальных машин и кластеров Kubernetes продолжается в штатном режиме, автоматизированные сценарии и API-вызовы не прерываются. Меньше времени уходит на планирование окон обслуживания — больше на поддержание актуальности патчей.

Подробности — в статье о vCenter Quick Patch.

Упрощение обслуживания vCenter

Помимо Quick Patch, в версии 9.1 улучшены и другие аспекты обслуживания vCenter.

Обновление vCenter с сокращённым временем простоя (Reduced Downtime Upgrade, RDU) теперь поддерживает работу с онлайн-репозиторием. Это упрощает использование метода RDU для подключённых к интернету экземпляров vCenter. Автономный метод с использованием примонтированного ISO по-прежнему доступен. Последующие патчи, обновления и апгрейды vCenter 9.1.x и более поздних версий также можно применять через RDU с онлайн-репозиторием, что значительно упрощает эксплуатацию для подключённых инсталляций.

В vCenter появился новый API, с помощью которого сторонние компоненты могут получать уведомления о планируемом или текущем техническом обслуживании. Обратный прокси Envoy будет отдавать заголовок 503 с информацией о том, что vCenter находится на обслуживании, и указанием ожидаемого времени завершения.

При выполнении мажорных апгрейдов (с 8.x до 9.1.0) или минорных обновлений (с 9.0.x до 9.1.0) методом RDU версия аппаратного обеспечения виртуальной машины vCenter автоматически повышается с версии 10 до версии 17, поскольку создаётся новая ВМ vCenter. При выполнении in-place обновления (с 9.0.x до 9.1.0) версию аппаратного обеспечения ВМ vCenter потребуется обновить вручную — эта процедура требует выключения ВМ vCenter.

Изменение ресурсов vCenter через единый API

В VCF 9.1 появился новый API, упрощающий масштабирование ресурсов vCenter. Для увеличения объёма вычислительных ресурсов и дискового пространства vCenter достаточно одного вызова API и перезагрузки.

Вызов API можно инициировать из Developer Center API Explorer в интерфейсе vCenter. API называется deployment/size и использует метод PATCH.

Упрощение обслуживания хостов ESX

Образы, создаваемые и управляемые через vSphere Lifecycle Manager, теперь включают контрольную сумму SHA256. Она позволяет проверять целостность образов при экспорте и импорте в другие экземпляры vCenter: администратор может сравнить контрольные суммы на источнике и целевом сервере. Речь идёт о контрольной сумме именно определения образа, а не VIB-файлов ESX.

В предыдущих версиях vSphere Lifecycle Manager проверял актуальность прошивок и драйверов устройств по HCL только при наличии стороннего Hardware Support Manager (HSM). Начиная с версии 9.1 вывод информации о текущих драйверах и прошивках устройств, а также их валидация по HCL выполняются для кластеров vSAN даже в отсутствие HSM. Некоторые устройства могут не сообщать данные о прошивке без соответствующего HSM. Это обеспечивает базовый уровень проверки устройств в кластере vSAN.

Подготовка кластеров vSphere с образом и конфигурацией

Zero Touch Provisioning (ZTP) строится на базе существующей инфраструктуры vSphere Auto-Deploy. Механизм задействует современные протоколы загрузки — UEFI HTTP/S Boot — и поддерживает актуальные серверные конфигурации, включая Secure Boot и TPM. ZTP не требует внешнего TFTP-сервера: достаточно настроить URL загрузки UEFI, указывающий на vCenter, и загрузить хост по сети. Если UEFI не поддерживает настройку статического IP для загрузки, потребуется DHCP-сервер.

Образ ESX и конфигурация определяются расположением кластера, выбранным при настройке правила развёртывания. Если для целевого кластера не настроен профиль конфигурации vSphere (VCP), хост загрузится и присоединится к кластеру с конфигурацией по умолчанию.

Быстрое и менее затратное обновление кластеров vSphere

ESX Live Patch включён по умолчанию для всех кластеров и автоматически применяется, если устанавливаемый патч поддерживает этот режим. Если патч несовместим с Live Patch, по умолчанию используется стандартный метод с переходом в режим обслуживания и перезагрузкой хоста.

Параметр можно изменить, включив принудительное применение Live Patch. В этом режиме исправление будет выполняться только через Live Patch, а для хостов, требующих режима обслуживания, процесс патчинга будет заблокирован. Настройки можно задать как на уровне кластера, так и на уровне vCenter — параметры vCenter применяются ко всем кластерам, если они не переопределены на уровне кластера.

ESX Live Patch теперь поддерживает серверы с включённым TPM. Пользователям не нужно отключать TPM или отказываться от Live Patch при использовании ESX 9.1 и более поздних версий.

Поддержка Live Patch расширена: охватывает больше компонентов vmkernel и обеспечивает более высокую производительность при патчинге ядра. Теперь механизм поддерживает дополнительные пользовательские демоны и сервисы, включая демоны vSAN, базовые демоны хранилища и соответствующие библиотеки.

Расширение интеграции с механизмом Desired State Configuration

Профили конфигурации vSphere (vSphere Configuration Profiles) обеспечивают соответствие изменений конфигурации и операций по устранению отклонений требованиям vSAN. Политики режима обслуживания vSAN и политики доступности объектов соблюдаются при исправлении кластеров vSAN. Расширенная конфигурация vSAN может применяться на уровне всего кластера.

Профили конфигурации vSphere используются для настройки memory tiering на хостах кластера. Устройства NVMe могут быть выделены для memory tiering; дополнительное устройство NVMe опционально может быть задействовано в качестве зеркального устройства для программного зеркалирования.

Профили конфигурации vSphere обеспечивают конфигурацию хостов при установке через Zero Touch Provisioning, а также поддерживают начальную настройку vSphere Distributed Switch в процессе развёртывания хоста.

Оптимизация Desired State Configuration

При добавлении новых хостов в кластеры с включёнными профилями конфигурации vSphere желаемая конфигурация автоматически применяется к входящему хосту. Специфичные для хоста атрибуты (например, IP-адреса) извлекаются из него автоматически и добавляются в соответствующий раздел профиля кластера.

Автоматическое устранение отклонений отключено по умолчанию и может быть включено как на уровне vCenter, так и на уровне отдельного кластера. Подробности — в руководстве How to Configure the vSphere Lifecycle Manager Remediation Settings.

Автоматическое управление сертификатами

Сертификат TLS для vCenter теперь обновляется автоматически за 5 дней до истечения срока действия. Сертификат ESX обновляется за 30 дней до истечения. Порог для ESX настраивается через расширенные параметры vCenter Server с помощью параметра vpxd.certmgmt.certs.autoRenewThreshold.

В обоих случаях автоматическое обновление выполняется для сертификатов, управляемых VMCA. Сертификаты, выданные внешними центрами сертификации, не обновляются автоматически — ответственность за их управление лежит на администраторе.

Если до истечения срока действия корневого сертификата VMCA остаётся менее 1 года, в процессе обновления vCenter автоматически обновляются корневой сертификат VMCA, а также дочерние сертификаты решений. Сертификаты TLS для vCenter и ESX в рамках этой операции не обновляются.

Масштабируемость, стабильность и производительность

В крупных и сверхкрупных развёртываниях vCenter ожидается увеличение числа операций в минуту до 25%. Это касается множества операций с виртуальными машинами и хостами, а также изменений конфигурации. Масштаб одновременных операций резервного копирования ВМ увеличен до 500–1000 в зависимости от размера vCenter. Операции резервного копирования ВМ теперь защищены от бесконтрольного потребления всех ресурсов vCenter. Передача файлов использует выделенные потоки, что исключает влияние на другие операции vCenter. Расширенные параметры vCenter для операций резервного копирования позволяют настраивать масштабируемость под конкретную среду.

Новый API мониторинга утилизации vCenter позволяет отслеживать активные подключения и сравнивать их с максимально допустимыми лимитами. Появилась возможность отслеживать количество запросов ко всем сервисам vCenter и контролировать, чтобы их интенсивность не превышала допустимых порогов.

Введены два новых оповещения — High Session Count и Increased Request Load — для сигнализации о нагрузке на один или несколько сервисов vCenter. Оповещение High Session Count срабатывает, когда число сессий приближается к лимиту (по умолчанию 3000); в сообщении указываются IP-адреса и имена пяти пользователей, создавших наибольшую нагрузку с более чем 100 сессиями каждый. При изменении состава топ-5 пользователей генерируется новое событие. В список могут попасть любые пользователи, включая сервисные аккаунты. Оповещение Increased Request Load срабатывает при достижении лимита активных запросов к конечной точке сервиса (по умолчанию 1024 для большинства конечных точек) и содержит информацию о затронутых сервисах и конечных точках.

Гибкая настройка виртуальных машин

Для поддержки миграции с VMware Cloud Director (vCD) на VMware Cloud Foundation Automation (VCFA) гостевой API настройки ОС (Guest OS Customization, GOSC) дополнен следующими возможностями, обеспечивающими паритет с функциями vCD:

• Установка пароля учётной записи root в Linux
• Сброс пароля учётной записи root в Linux
• Сброс паролей учётных записей группы администраторов в Windows
• Выполнение скриптов настройки в Windows

Теперь администраторы могут явно отключить IPv4 и настроить сеть только для IPv6 в гостевой настройке — как через интерфейс, так и через API. Это устраняет прежнее требование сохранять параллельную конфигурацию IPv4.

Появилась возможность выполнять настройку только сетевых параметров виртуальной машины — для выключенных и для работающих ВМ, что позволяет применять изменения сетевой конфигурации в реальном времени.

Сохранение производительности рабочих нагрузок во время обслуживания хоста

DRS-оптимизированная эвакуация через vMotion (DRS Optimized vMotion Evacuation) гарантирует, что виртуальные машины будут мигрированы с хоста только при наличии достаточной вычислительной ёмкости для их размещения без конкуренции за ресурсы. DRS может предварительно перебалансировать оставшиеся хосты, чтобы создать свободную ёмкость для эвакуируемых ВМ.

При переводе хоста в режим обслуживания для кластеров с включённым DRS доступны два варианта:

Стандартная эвакуация через vMotion: виртуальные машины переносятся на другие хосты в том же кластере при условии совместимости целевых хостов и соответствия требованиям по ресурсам.

Нон-деструктивная эвакуация через vMotion: виртуальные машины переносятся только в том случае, если их текущие вычислительные потребности могут быть удовлетворены целевыми хостами.

Примечание: термин «нон-деструктивная» применительно к новому режиму эвакуации не означает, что стандартная эвакуация как-либо вредит рабочим нагрузкам. Он лишь указывает на то, что при этом режиме эвакуация выполняется только без создания конкуренции за ресурсы на целевых хостах.

Улучшение утилизации ресурсов vMotion и снижение конкуренции

Максимальное количество одновременных задач vMotion по умолчанию равно 8. В предыдущих версиях, если 8 задач vMotion выполнялись одновременно в рамках пакетной операции, новые задачи не начинались до завершения всех предыдущих. Начиная с vSphere 9.1, как только одна задача vMotion завершается и освобождается слот, следующая задача может немедленно стартовать.

Усовершенствованная обработка задач vMotion обеспечивает более равномерное распределение нагрузки по хостам кластера. Число хостов, испытывающих пиковую одновременную нагрузку vMotion, сокращается, а сетевые ресурсы и ресурсы хранилища используются эффективнее.

Более высокая пропускная способность vMotion и сокращение времени миграции

В VCF 9.1 появилась возможность разгрузки операций зашифрованного vMotion на Intel QAT (QuickAssist Technology). Это освобождает ценные ресурсы CPU и возвращает их рабочим нагрузкам.

Для максимально эффективного использования ресурсов в VCF задействована технология Intel QAT (QuickAssist Technology) для ускорения инфраструктурных операций. Перенос «тяжёлой» части задач vMotion на выделенное аппаратное обеспечение позволяет вернуть ценные ядра CPU реальным рабочим нагрузкам. Intel QAT берёт на себя шифрование данных при выполнении операций vMotion.

Оптимизированная масштабируемость и производительность для современных CPU

Планировщик Topology Aware Scheduler перешёл на событийно-ориентированный механизм встроенного обновления, что обеспечивает более согласованное и сбалансированное размещение по NUMA-узлам.

Архитектура NUMA (Non-Uniform Memory Access) используется для повышения масштабируемости и производительности серверов с несколькими процессорными сокетами. Планировщик — компонент ядра ESX, отвечающий за управление размещением виртуальных машин и балансировкой нагрузки по NUMA-узлам с целью минимизации задержек доступа к памяти и оптимального использования ресурсов CPU и памяти рабочими нагрузками.

Topology Aware Scheduler оптимизирован для нового поколения высокоплотных процессоров: улучшена модель оценки эффективности использования CPU и памяти. Существующий планировщик при принятии решений о размещении в основном учитывал конкуренцию за CPU (ready time). Topology Aware Scheduler учитывает не только конкуренцию за CPU, но и конкуренцию за кэш и пропускную способность памяти.

Для систем с асимметричной топологией NUMA, где расстояние между некоторыми парами узлов существенно больше, чем между другими, Topology Aware Scheduler может размещать смежные NUMA-клиенты одной ВМ на подмножестве узлов, расположенных ближе друг к другу.

Готовность к работе с AI-платформами различных производителей

В VCF 9.1 расширена поддержка Enhanced DirectPath I/O.

Речь идёт не просто о «проброске» оборудования, а о его виртуализации — это обеспечивает лучшую утилизацию ресурсов и возможность выполнения операций обслуживания и масштабирования без остановки AI-рабочих нагрузок. Поддержка новых аппаратных устройств в VCF 9.1 открывает доступ ко многим преимуществам виртуализации, включая stun-based операции и быстрое приостановление и возобновление работы. Среди этих преимуществ:

• Storage vMotion
• Снапшоты (включая снапшоты памяти)
• Операции реконфигурации дисков
• Горячее добавление и удаление виртуальных устройств
• ESX Live Patch

ESX 9.1 расширяет свои возможности, внедряя поддержку виртуализации IOMMU для CPU AMD. Теперь администраторы могут задействовать устройства PCI passthrough на системах на базе AMD, повышая производительность и обеспечивая прямой доступ к оборудованию для виртуальных машин.

AMD vIOMMU (Virtual I/O Memory Management Unit) — аппаратно-ускоренная технология, обеспечивающая безопасный высокопроизводительный прямой доступ к памяти (DMA) для виртуальных машин за счёт прямого доступа гостевых систем к регистрам MMIO.

Flow Processing Offload (FPO) и аппаратное направление трафика (hardware steering) повышают эффективность центра обработки данных, перенося обработку сложных сетевых правил с CPU на выделенное аппаратное обеспечение. Это обеспечивает производительность на уровне линейной скорости и быструю масштабируемость виртуализированных сред, освобождая ресурсы CPU для бизнес-приложений.

Enhanced DirectPath I/O поддерживает прямую связь GPU-to-GPU через RDMA over Converged Ethernet (RoCE). Решение предназначено для организаций, выполняющих массивные AI-рабочие нагрузки или высокоскоростную обработку данных: оно обеспечивает производительность, близкую к нативной (необходимую для AI), без отказа от инструментов управления, которые упрощают эксплуатацию виртуализованных ЦОД.

GPU NVIDIA, используемые для vGPU, теперь можно настроить одновременно для тайм-слайсинга и режима MIG, что обеспечивает ещё более эффективное совместное использование ресурсов и повышение плотности.

Современные кибератаки перестали быть точечными ударами по приложениям — теперь они нацелены на саму инфраструктуру. Целенаправленные постоянные угрозы, программы-вымогатели и атаки supply chain бьют именно по тем фундаментальным слоям, на которых работают рабочие нагрузки. Защита фундамента — это уже не опция, а обязательное условие для эксплуатации безопасной и устойчивой инфраструктуры частного облака в эпоху, когда кибератаки, ранее опиравшиеся на ручной хакинг, превратились в управляемые AI-кампании, способные к самоэволюции.

По мере масштабирования корпоративных развёртываний AI архитектура безопасности становится стратегическим приоритетом. Чтобы обеспечить доверенное взаимодействие между людьми, данными и системами AI, требуется продуманный подход к защите инфраструктуры; единая платформа частного облака даёт здесь существенное преимущество с точки зрения архитектурного контроля, суверенитета данных и соответствия регуляторным требованиям.

VMware Cloud Foundation (VCF) предоставляет валидированный и проверенный на целостность фундамент инфраструктуры, на который можно опереться при защите чувствительных данных и обеспечении непрерывности бизнеса в условиях изощрённых угроз. Вместо неявного доверия VCF реализует непрерывную верификацию системы, обеспечивая глубокую видимость платформы и мониторинг целостности в реальном времени. Усиленная программно-определяемая инфраструктура VCF со встроенными средствами контроля безопасности даёт предприятиям необходимый запас устойчивости, чтобы опережать угрозы, которые благодаря ИИ движутся быстрее и постоянно адаптируются.

Безопасность платформы в VCF 9.1

Каждый новый выпуск VCF приносит улучшения и расширения возможностей безопасности платформы. В VCF 9.1 представлены свежие функции платформенной безопасности, необходимые для поддержки промышленных развёртываний AI. Новый релиз защищает AI-нагрузки, проприетарные модели и чувствительные данные за счёт интеграции механизмов безопасности на всём стеке инфраструктуры — от гипервизора до уровня приложений.

Ключевые платформенные функции безопасности VCF 9.1 распределены по пяти категориям:

• Обнаружение и предотвращение угроз усиливает защиту гипервизора и ускоряет установку патчей без простоев.
• Устойчивость рабочих нагрузок обеспечивает непрерывную работу и восстановимость приложений за счёт аппаратной изоляции и кроссплатформенной репликации.
• Шифрование данных защищает данные в процессе обработки, при передаче и в покое на всём стеке.
• Аудит и мониторинг предоставляют единое управление журналами и централизованный аудиторский след для быстрого форензик-анализа.
• Идентификация и доступ обеспечивают принцип Zero Trust за счёт SSO уровня фабрики, политик паролей и управления сертификатами.

В совокупности эти пять направлений формируют эшелонированную оборону, необходимую частному облаку и промышленным AI-нагрузкам в противостоянии всё более способным, адаптивным и автоматизированным противникам.

Обнаружение и предотвращение угроз

VCF 9.1 продолжает добавлять новые возможности в направлении проактивных оповещений и интеллектуального анализа, а также верификации целостности и конфигурации инфраструктуры — всё это улучшает обнаружение и предотвращение угроз. В этом релизе значительно расширены возможности патчинга VCF.

Live Patching для хостов с включённым TPM

В VCF 9.1 функция live patching в vSphere продолжает развиваться: обновления безопасности можно применять к кластерам без миграции рабочих нагрузок с целевых хостов и без перевода хостов в полный режим обслуживания. Релиз также закрывает пробел, который ранее не позволял хостам с включённым TPM на ESX участвовать в рабочем процессе live patching. Установка патчей без простоев особенно выгодна для бизнес-критичных приложений — таких как сервисы AI-инференса и агентные AI-приложения, для которых требуется непрерывная доступность ради соблюдения SLA.

Quick Patching для vCenter

Функция Quick Patch позволяет VMware vCenter получать патчи безопасности, оставаясь в работающем состоянии. Применение обновления vCenter теперь занимает приблизительно 5 минут без прерывания рабочих нагрузок — против примерно 20 минут простоя и до 40 минут общего времени операции в случае обычного патча. Снижение операционной стоимости патчинга vCenter устраняет одну из частых точек трения, из-за которой обновления одного из самых критичных управленческих компонентов инфраструктуры регулярно откладываются.

С возможностями Live Patching и Quick Patching VCF 9.1 расширяет способность применять исправления безопасности в большем масштабе и с большей скоростью — без обновлений всего стека и без прерывания работы нагрузок.

Интеграция EDR для ESX

Хосты ESX теперь могут запускать EDR-агенты от партнёров по безопасности непосредственно на гипервизоре. EDR-агент работает в изолированном контейнере на хосте, отделённом от ядра системы, чтобы не вмешиваться в нормальную работу. Он отслеживает события — например, запуск и завершение процессов, установление сетевых соединений — и передаёт их на платформу управления вендора средств защиты. Поддержка EDR доступна в ESX 9.1 и требует, чтобы вендоры EDR предоставили совместимых агентов. Организациям, заинтересованным в использовании этих возможностей, следует уточнить у своего EDR-вендора, готовы ли его агенты.

Мониторинг целостности файлов

В VCF 9.1 появилась функция мониторинга целостности файлов (File Integrity Monitoring, FIM), соответствующая требованиям NIST и PCI DSS. Она выявляет изменения, внесённые вредоносным ПО или злоумышленниками, в статические файлы и бинарники, установленные vCenter. FIM включён по умолчанию и запускается каждые четыре часа, фиксируя злонамеренные, непреднамеренные изменения или повреждения установленных файлов. Администраторы VCF могут получить FIM-отчёт через API или передавать FIM-логи в VCF Operations for Logs через службу syslog.

User-Level Monitor

User-Level Monitor (ULM) поставляется в VCF 9.1 как монитор по умолчанию для всех виртуальных машин. ULM полностью переписывает виртуальный монитор машин (Virtual Machine Monitor, VMM) ESX — компонент, который управлял исполнением виртуальных машин на физическом железе с 1998 года. Ранее VMM работал с максимальными привилегиями ОС, а значит, любая уязвимость могла скомпрометировать весь хост и все ВМ на нём. ULM переносит монитор в пользовательский режим с пониженными привилегиями, ограничивая потенциальный ущерб от эксплойтов. Переработанный интерфейс ядра трактует все входные данные как недоверенные; адресное пространство исключает секреты хоста и память других ВМ; упрощённая архитектура значительно сокращает поверхность атаки и сложность гипервизора.

Устойчивость рабочих нагрузок

Усовершенствование vSphere Pod

Один из способов, которыми VCF обеспечивает изоляцию контейнерных нагрузок, — это vSphere Pods: контейнеры запускаются напрямую внутри управляемых ESX виртуальных машин, что сочетает скорость и плотность контейнеров с аппаратной изоляцией гипервизора. PodVM (vSphere Pods) используются для запуска одного или нескольких контейнерных инстансов без необходимости разворачивать кластер Kubernetes. На vSphere Pods построены сервисы Supervisor, и теперь они доступны через новый UI Container Service.

vSphere Pods используют Container Runtime Executive (CRX), обеспечивающий лёгкую и высокопроизводительную среду, которая загружается за секунды. Это делает их идеальным выбором для нагрузок с повышенными требованиями к безопасности, где необходима строгая изоляция ядер между приложениями, либо для ресурсоёмких микросервисов, которым нужны продвинутое планирование и предиктивные возможности DRS в ESX.

По мере увеличения числа сервисов Supervisor накладные расходы памяти PodVM могут стать узким местом. Благодаря оптимизации памяти PodVM внутренние тесты показывают, что накладные расходы памяти снижаются примерно на 75% по сравнению со стандартной ВМ — за счёт совместного использования образа загрузки между инстансами PodVM на одном хосте. Кроме того, внутренние тесты подтверждают, что PodVM загружается до 70% быстрее, чем типичная ВМ.

Новый сервис Container Service позволяет разворачивать отдельные контейнеры без необходимости управлять полноценным кластером Kubernetes. Используя изолированные runtime-среды внутри vSphere Pods, он даёт возможность запускать отдельные контейнеры, не разворачивая и не обслуживая Kubernetes-кластер целиком.

В этом релизе также добавлен потоковый вывод STDOUT/STDERR в реальном времени со всех контейнеров внутри PodVM на внешние syslog-серверы. Это применимо только к vSphere Pods и не распространяется на гостевые кластерные нагрузки VMware vSphere Kubernetes Service (VKS).

Multi-Source Replication для кластеров vSAN

В VCF 9.0 в vSAN была представлена репликация vSAN-to-vSAN, обеспечивающая защиту ВМ из одного vSAN-кластера в другой. В нынешнем релизе эта возможность расширена дальше. Теперь можно реплицировать или защищать ВМ из любого источника — например, из хранилища VMFS или NFS — на vSAN-цель. Это даёт большую гибкость в защите существующих сред VCF, где может присутствовать смешанный набор платформ хранения. Теперь возможно защищать все ВМ среды через единую цель репликации и единый рабочий процесс — независимо от того, на какой платформе хранения они в данный момент находятся, — с политиками снапшотов и репликацией, действующими на всю инфраструктуру.

Возможности репликации доступны через VMware Site Recovery Manager (SRM) или решение VMware Advanced Cyber Compliance.

Шифрование данных

VCF 9.1 добавляет и расширяет возможности шифрования по всему стеку, включая улучшения для данных в покое, данных в движении и нагрузок confidential computing.

Confidential Computing — теперь в общедоступной версии

Confidential Computing запускает чувствительные нагрузки внутри аппаратно зашифрованных областей памяти, которые остаются недоступными даже для гипервизора, защищая данные в процессе использования на разделяемой инфраструктуре частного облака. VCF поддерживал более ранние поколения этой технологии уже несколько лет; VCF 9.1 завершает работу над поддержкой текущих реализаций — Intel TDX и AMD SEV-SNP, — переводя их в категорию общедоступных (general availability). Одно из практических улучшений — повторное включение Quick Boot на хостах, где активен Confidential Computing: раньше хосты, использующие Intel TDX или AMD SEV-SNP, не могли воспользоваться Quick Boot — функцией, позволяющей ESX перезапускаться без полного цикла аппаратной инициализации и тем самым сокращающей окна обслуживания.

Дополнительно VCF Operations теперь автоматически профилирует ESX-хосты и определяет, какие из них способны выполнять конфиденциальные ВМ и контейнеры. Это снимает с архитекторов гадания при размещении чувствительных нагрузок на защищённом оборудовании. Операторы также могут видеть, активирован ли Confidential Computing на подходящем хосте.

Confidential Computing в VCF доступен через решение VMware Advanced Cyber Compliance.

Ускоренный шифрованный vMotion с технологией Intel QuickAssist (QAT)

vMotion сам по себе может быть ресурсоёмким процессом, и эта нагрузка возрастает, когда включено шифрование. По мере того как рабочие нагрузки становятся крупнее, а частота операций vMotion растёт, потребление ресурсов на эту задачу заметно увеличивается. Перенос функции шифрования на аппаратное ускорение требует меньше критически важных ресурсов, которые освобождаются для других приложений, что в итоге сокращает затраты.

QAT включён по умолчанию на поддерживаемом оборудовании, обеспечивая более плавный пользовательский опыт и упрощённое управление жизненным циклом.

Шифрование данных в покое для vSAN Global Deduplication

В связке с переводом vSAN Global Deduplication в общедоступную версию в VCF 9.1 кластеры vSAN, использующие глобальную дедупликацию, теперь поддерживают шифрование данных в покое (Data-at-Rest Encryption). Включить Data-at-Rest Encryption можно на уровне отдельного кластера, одновременно используя на том же кластере vSAN Global Deduplication — без каких-либо компромиссов между этими двумя функциями. Дедупликация работает как фоновая постобработка и совместима с шифрованием данных в покое; включение шифрования не влияет на коэффициенты дедупликации.

Аудит и мониторинг

Централизованное управление журналами

VCF 9.1 улучшает управление логами, полностью интегрируя возможности отдельного UI VCF Operations for Logs внутрь VCF Operations и предоставляя администраторам и операторам VCF единый интерфейс для всех задач управления журналами. В интеграцию входят правила обработки логов, администрирование логов, публичные API для логов, глобальные настройки управления кластером логов, а также улучшения страницы анализа логов.

Отдельный UI больше не требуется, поскольку все возможности встроены непосредственно в VCF Operations.

Аудиторский след (Audit Trail)

Форматы лог-записей и аудиторских записей теперь стандартизированы между компонентами VCF.

Новый Audit Trail в VCF Operations идёт дальше и предоставляет централизованное представление пользовательской активности с временными срезами по всем компонентам (включая VKS), упрощая разбор для форензики, выявление ключевых событий и сокращая время аудита. Когда меняются правила межсетевого экрана или фиксируются неудачные попытки входа, операторы могут проследить всю цепочку событий через весь стек.

Идентификация и доступ

VCF 9.1 расширяет возможности единого SSO, управления паролями и сертификатами, представленные в предыдущем релизе, — добавляя более широкое покрытие компонентов, средства управления на уровне фабрики и новые интеграции с хранилищами секретов и центрами сертификации.

Усовершенствование Identity Broker

VCF Identity Broker (VIDB) получил расширенные параметры конфигурации и улучшения развёртывания. VIDB обеспечивает SSO-связь между компонентами VCF и внешним поставщиком идентификации (Identity Provider, IDP) или службой каталогов. Identity Broker теперь устанавливается в момент развёртывания или обновления VCF и больше не требует отдельной загрузки в качестве предусловия для настройки единого входа.

Identity Broker можно настраивать в embedded-режиме или режиме appliance — через VCF Operations или API. Развёртывание Identity Broker в виде кластера из трёх узлов обеспечивает более высокую производительность, масштабируемость и высокую доступность; такой вариант рекомендован для промышленной эксплуатации. Узлы Identity Broker теперь могут разворачиваться за пределами management-кластера.

VCF 9.x также предоставляет скриптовый рабочий процесс для организаций, обновившихся с VCF 5.x, — позволяющий без прерывания работы мигрировать пользователей и группы из VMware Identity Manager (VIDM) в Identity Broker. В процессе обновления Identity Broker разворачивается автоматически. Скрипт запускается уже после завершения обновления. Далее Identity Broker можно интегрировать с выбранным поставщиком идентификации; существующие пользователи и группы при этом не затрагиваются.

Усовершенствование управления паролями

VCF Operations 9.1 расширяет управление паролями, добавляя политики уровня фабрики, интеграцию с хранилищами секретов и покрытие дополнительных компонентов.

Теперь возможно задавать единые политики паролей между компонентами VCF и проводить проверки соответствия паролей с последующей коррекцией. Созданные политики применяются на уровне фабрики VCF или для отдельных компонентов VCF. Кроме того, администраторы могут управлять паролями для VCF Operations workload mobility (ранее известного как HCX) и балансировщиков Avi, развёрнутых или обновлённых до VCF 9.1.

Пароли break-glass-учётных записей больше не сохраняются — что устраняет одну из распространённых причин для процедур принудительной смены паролей. Дополнительно новые API для интеграции с корпоративными хранилищами паролей поддерживают сторонние инструменты — в частности, CyberArk. Корпоративные парольные хранилища, управляемые через API, потребуют плагина для VCF.

Усовершенствование управления сертификатами

В VCF 9.1 добавлены конфигурация центров сертификации на уровне фабрики, расширенная поддержка Microsoft CA и OpenSSL, а также массовые операции с сертификатами. Центр сертификации (Certificate Authority, CA) теперь настраивается на уровне фабрики VCF, а не отдельного инстанса, что позволяет управлять сертификатами на уровне всей фабрики.

Поддержка Microsoft CA и OpenSSL расширена и теперь охватывает как компоненты VCF instance, так и компоненты управления VCF. В предыдущем релизе Microsoft CA и OpenSSL поддерживались только для компонентов VCF instance (vCenter, NSX и ESX), тогда как компоненты управления можно было настраивать исключительно с использованием Microsoft CA.

В UI VCF Operations операторы теперь могут выполнять массовые операции с сертификатами. Запросы на подпись сертификатов, их обновление и импорт — всё это выполняется пакетно, сокращая время и дополнительно упрощая операции по управлению сертификатами. API VCF Operations можно использовать для интеграции со сторонними решениями и автоматизации управления сертификатами для всех компонентов VCF.

Дополнительные материалы

VCF 9.1 содержит последние достижения технологии виртуализации VMware. Релиз объединяет Zero Trust-безопасность и устойчивость на каждом уровне: vSphere, NSX, vSAN, VMware vSphere Kubernetes Service, VCF Private AI Services, VCF Operations и VCF Automation, помогая организациям защитить инфраструктуру частного облака от продвинутых, ускоренных AI-угроз.

Для технического разбора темы можно посмотреть видео «What's New in Platform Security in VCF 9.1» на YouTube:

Также материалы по усилению безопасности, соответствию требованиям и часто задаваемые вопросы по конкретным функциям доступны в репозитории GitHub: https://brcm.tech/vcf-security.

Во времена, когда на счету каждый доллар или сотня рублей, а каждая минута простоя стоит дорого, команды, отвечающие за инфраструктуру, оказались в "идеальном шторме" вызовов: дефицит оборудования, который прогнозируется вплоть до 2027 года, изолированные среды, возникающие из-за сосуществования старых и современных архитектур, постоянно меняющиеся требования к компетенциям и нарастающая сложность управления установками, обновлениями и обслуживанием в разнородных системах. Параллельно с этим эволюция угроз и рост числа и изощрённости кибератак требуют детальной и точной видимости поведения гостевой ОС и активности рабочих нагрузок. Традиционные подходы перестают быть жизнеспособными: организации испытывают сильное давление, заставляющее минимизировать совокупную стоимость владения (TCO) и одновременно добиваться измеримой отдачи от каждой инвестиции. Нужна не просто большая инфраструктура — нужна более умная инфраструктура, которая по максимуму использует уже имеющиеся ресурсы за счёт инновационных подходов. Именно здесь vSphere в составе VMware Cloud Foundation (VCF) 9.1 меняет правила игры, привнося прорывные нововведения, которые фундаментально переопределяют экономику инфраструктуры, её производительность и безопасность.

Экономика модернизации без замены оборудования

В vSphere внедрён набор возможностей, нацеленных на то, чтобы выжать максимум из уже сделанных инфраструктурных инвестиций и снизить TCO. vSphere в VCF 9.1 также включает функции, существенно сокращающие накладные расходы и повышающие операционную эффективность. Речь идёт не о точечных улучшениях, а о фундаментальных сдвигах в том, как инфраструктура создаёт ценность.

Память по-новому: интеллектуальный NVMe-тиринг

Стоимость памяти долгое время оставалась ограничителем при масштабировании инфраструктуры, а сегодня этот фактор стал ещё острее из-за стремительно растущих цен на память на фоне всплеска интереса к AI. vSphere полностью меняет это уравнение. Усовершенствованная функция тиринга памяти на NVMe позволяет снизить TCO сервера до 40% и одновременно убирает операционные неудобства.

Что делает версию 9.1 по-настоящему трансформирующей — это устранение барьеров для внедрения. Например, отменяется требование перезагрузки для включения тиринга памяти. Уведомления в интерфейсе позволят без усилий определять подходящие кластеры и рабочие нагрузки, а проактивный мониторинг состояния устройств обеспечит их замену ещё до того, как они выйдут из строя.

Появление зеркалирования RAID 1 для тиринга памяти обеспечивает критически важную отказоустойчивость, не позволяя сбоям отдельных устройств перерастать в масштабные простои виртуальных машин. Для нагрузок, активно работающих с данными, — аналитики больших данных, e-commerce-платформ и сервисов видеостриминга — это означает резкое расширение доступной памяти без пропорционального наращивания «железа». При улучшенном соотношении ядер и памяти организации добиваются более плотной консолидации ВМ и более высокой загрузки CPU, что усиливает экономический эффект от снижения TCO.

Время — деньги: Quick Patching для vCenter

Требования к безопасности и соответствию нормативам диктуют необходимость регулярного патчинга, однако традиционные окна обслуживания дорого обходятся: они нарушают работу и истощают ресурсы ИТ-команд. Функция Quick Patching для vCenter сокращает общее время операции примерно на 80% — окно патчинга уменьшается приблизительно с 30 минут до менее чем 5 минут.

Это резкое сокращение — не только про экономию времени. Quick Patching интеллектуально классифицирует сервисы vCenter по степени их влияния и оптимизирует процедуру обновления под каждый тип. В итоге улучшается соблюдение требований по критическим патчам, снижается риск ручных ошибок и заметно уменьшается административная нагрузка. В то время как у конкурентов на ручной патчинг уходят значительные человеко-часы, автоматизированный подход vSphere превращается в конкурентное преимущество, которое со временем только усиливается.

Эластичное развертывание в любых масштабах

Развёртывание инфраструктуры исторически было медленным ручным процессом, что затрудняло быстрое масштабирование. Технология vSphere Elastic Provisioning (Zero-Touch Provisioning) превращает это узкое место в отлаженную операцию. Используя UEFI HTTP для безопасной загрузки и vSphere Configuration Profiles для настройки среды в желаемом состоянии, организации могут быстро разворачивать инфраструктуру в масштабе при минимальном ручном вмешательстве.

Оптимизация производительности для требовательных нагрузок

По мере того как рабочие нагрузки становятся всё более ресурсоёмкими, а архитектуры процессоров эволюционируют, традиционные подходы к оптимизации производительности создают узкие места, ограничивающие масштабируемость и эффективность. vSphere в VCF 9.1 решает эти задачи в лоб с помощью интеллектуальных улучшений производительности, которые устраняют накладные расходы, не жертвуя при этом ни безопасностью, ни непрерывностью операций.

Производительность без накладных расходов: ускорение шифрованного vMotion

Для ресурсоёмких нагрузок с большими буферами кадров традиционный зашифрованный vMotion способен создавать существенные узкие места по производительности во время живой миграции. vSphere в VCF 9.1 задействует технологию Intel Quick Assist Technology (QAT), чтобы выгружать на сторону железа задачи шифрования, дешифрования и сжатия с CPU хоста в процессе vMotion.

Какой эффект? Значительно ускоряется этап переключения vMotion — и при этом не страдает безопасность. Организации сохраняют непрерывность работы даже для самых требовательных нагрузок, безопасно передавая данные без потерь в производительности. В средах, где каждая секунда миграции имеет значение — будь то окна обслуживания, балансировка нагрузки или восстановление после сбоев, — такая оптимизация даёт ощутимую бизнес-ценность и операционную гибкость.

Максимум производительности: планирование с учётом топологии

Процессоры с большим числом ядер раздвигают границы прежних NUMA-архитектур, создавая такие проблемы, как переполнение узлов, лишние миграции и неоптимальная производительность на системах AMD и системах с включённым SNC. Планирование с учётом топологии в vSphere меняет то, как платформа работает с этими процессорами высокой плотности нового поколения.

Обновлённый NUMA-планировщик теперь работает скорее по принципу DRS: используется та же модель справедливости с пулами ресурсов и параметрами min/max shares, а для эффективности применяется многоресурсная модель «качества», учитывающая стоимость миграции страниц памяти. Такой интеллектуальный подход принимает во внимание архитектурные особенности процессоров нового поколения и оптимизирует алгоритмы планирования, обеспечивая лучшую производительность, более эффективное использование ресурсов и более предсказуемое поведение нагрузок на самых разных аппаратных конфигурациях.

Безопасность: встроенная защита на всех уровнях стека

vSphere представляет собой по-настоящему защищённую платформу, расширяющую защиту до данных в обработке (data-in-use), детектирующую угрозы в реальном времени и обеспечивающую соблюдение нормативных требований и отраслевых рекомендаций по конфигурации безопасности «из коробки».

Безопасность без простоев: расширенный Live Patching

По мере того как организации переходят на серверы с TPM (а такие машины составляют почти 90% нового железа), vSphere в VCF 9.1 распространяет поддержку Live Patching на хосты с TPM и включает эту функцию по умолчанию. Возможность позволяет применять важные патчи к инфраструктуре платформы ESX без перевода хостов в офлайн и без эвакуации виртуальных машин, доставляя критические обновления безопасности быстро в рамках фиксированных SLA и поддерживая надёжные обновления без ошибок.

Confidential Computing: защита данных в обработке

Защита данных не ограничивается хранением и передачей: следующий рубеж — это защита данных непосредственно в процессе их обработки. vSphere в VCF 9.1 переводит в общую доступность Confidential Computing с поддержкой Intel TDX и AMD SEV-SNP. Эти аппаратные средства шифрования памяти и контроля её целостности изолируют рабочие нагрузки от инфраструктурного стека, формируя защищённые Trust Domains (у Intel) и Confidential VMs (у AMD), благодаря чему безопасность становится неотъемлемым свойством платформы.

Глубокая видимость: интеграция с EDR

Традиционные средства Endpoint Detection and Response (EDR) хорошо справляются с мониторингом гостевых операционных систем, однако часто не имеют видимости в сам хост ESX. vSphere в VCF 9.1 позволяет агентам EDR от сторонних производителей интегрироваться непосредственно в гипервизор ESX и анализировать события на уровне процессов, файлов и сети на предмет подозрительной активности. Такая глубокая интеграция средств обнаружения угроз прямо в гипервизор крайне важна для выявления горизонтального перемещения злоумышленников, бесфайлового вредоносного ПО и эксплойтов нулевого дня — и всё это без появления узких мест по производительности.

Инфраструктура, которая окупает себя

vSphere в VCF 9.1 — это фундаментальный сдвиг в экономике инфраструктуры. Максимально используя уже установленное оборудование через тиринг памяти на NVMe, сокращая операционные накладные расходы за счёт быстрого патчинга и эластичного провижининга, устраняя узкие места по производительности через интеллектуальную выгрузку задач и обеспечивая непрерывность работы благодаря Live Patching, организации превращают инфраструктуру из статьи затрат в стратегическое преимущество.

В условиях, когда дефицит оборудования сохраняется и каждая инвестиция должна приносить измеримую отдачу, vSphere в VCF 9.1 предлагает понятный путь вперёд: использовать то, что уже есть, оптимизировать то, как выстроены операции, и масштабироваться без пропорционального роста затрат.

Искусственный интеллект обладает огромным потенциалом для трансформации всех предприятий - IDC прогнозирует, что решения и сервисы AI окажут глобальное влияние на сумму 22,3 трлн долларов к 2030 году.

С учетом такого масштаба неудивительно, что предприятия стремятся использовать AI для повышения производительности во всех областях бизнеса. Однако им нужна комплексная стратегия, которая ускорит интеграцию AI в инфраструктуру дата-центров. С VMware Cloud Foundation Private AI Services компания Broadcom стремится помочь предприятиям раскрыть потенциал AI и повысить продуктивность при более низкой совокупной стоимости владения.

Реальный эффект: что говорят клиенты

Компании из разных отраслей уже развертывают VCF Private AI Services и получают экономию, приватность и безопасность для своих AI-нагрузок:

«Внедрив VCF Private AI Services, мы усилили возможности интеллектуальных сервисов», — говорит Тунг-Лян Чен, вице-президент Chunghwa Post. «Запуск AI в собственной инфраструктуре частного облака на базе VCF позволяет нам существенно снижать затраты и повышать эффективность автоматизированного обнаружения в реальном времени, одновременно обеспечивая бесшовную интеграцию с существующими системами».

«Анализ многолетних архивов новостей в публичном облаке обходится слишком дорого, а непредсказуемое ценообразование затрудняет планирование AI-проектов», — сказал V V Jacob, старший генеральный менеджер по системам Malayala Manorama Co Ltd. «Развернув VCF Private AI Services на существующей инфраструктуре VMware Cloud Foundation, мы сможем запускать AI-суммаризацию контента, генерацию заголовков и редакторскую помощь прямо в частном облаке. Мы считаем, что это даст нам приватность и безопасность, необходимые для защиты редакционных источников, а также предсказуемость затрат, которую обеспечивает локальная инфраструктура частного облака».

На днях был объявлен следующий выпуск VCF Private AI Services вместе с VCF 9.1. В новой версии для предприятий добавляется несколько важных функций.

Новые возможности

1. Приватность и безопасность

Broadcom помогает предприятиям создавать и развертывать приватные и безопасные AI-модели со встроенными возможностями защиты, предоставляемыми через VCF Private AI Services.

• Поддержка Model Context Protocol (MCP) с управлением. Благодаря поддержке MCP предприятия получают безопасный и стандартизированный способ интегрировать AI-ассистентов с внутренними репозиториями контента и внешними MCP-инструментами от Oracle, Microsoft SQL Server, ServiceNow, GitHub, Slack, PostgreSQL и других поставщиков без разработки и сопровождения собственных коннекторов.

2. Упрощение управления инфраструктурой

• Поддержка Google Documents. VCF Private AI Services теперь предоставит полноценную поддержку Google Workspace, включая Google Docs, Sheets и Slides, без необходимости экспортировать документы в PDF и загружать их в базу знаний. В дополнение к уже существующей поддержке Microsoft Word, Microsoft PowerPoint, PDF, CSV и других форматов предприятия получают доступ к очень широкому набору типов документов и смогут добиваться качественных результатов для AI-нагрузок.

• DirectPath Enablement для GPU. В этом выпуске VCF Private AI Services поддерживает DirectPath Enablement для инфраструктуры NVIDIA AI. Это обеспечит высокопроизводительный эксклюзивный доступ к GPU для одной виртуальной машины, которая сможет полностью использовать возможности GPU. С этой новой функцией предприятия смогут развертывать AI-проекты с NVIDIA GPU в режиме DirectPath.
• Поддержка последнего поколения NVIDIA Blackwell GPU. VCF теперь поддерживает новейшую серию GPU NVIDIA Blackwell. В дополнение к существующей поддержке NVIDIA RTX PRO 6000 Blackwell Server Edition объявлена поддержка NVIDIA HGX B200 и NVIDIA RTX PRO 4500 Blackwell Server Edition. Поддержка этих новых GPU Blackwell на VCF определяет следующий этап корпоративного AI с беспрецедентной производительностью, эффективностью и масштабом.
• Будущая поддержка. В одном из следующих выпусков VCF будет поддерживать NVIDIA HGX B300. VCF на NVIDIA HGX B300 позволит предприятиям без усилий масштабировать самые производительные AI-нагрузки и подготовить инфраструктуру к будущим требованиям.
• Поддержка NVIDIA HGX Platform с Blackwell GPU и NVLink Switch. VCF теперь поддерживает NVIDIA HGX platform с Blackwell GPU и NVLink Switch. Благодаря этой возможности предприятия смогут получить преимущества крупномасштабных AI-развертываний с VCF Private AI Services и платформой NVIDIA HGX. NVIDIA HGX объединяет всю мощь инфраструктуры NVIDIA AI, включая NVIDIA GPU, NVIDIA NVLink, NVLink Switch, NVIDIA networking и полностью оптимизированные AI software stacks, чтобы обеспечивать максимальную производительность AI-приложений и ускорять получение инсайтов в каждом дата-центре.
• Высокоскоростная сеть с Enhanced DirectPath I/O. VCF теперь поддерживает сетевые адаптеры NVIDIA ConnectX-7 и NVIDIA BlueField-3 с Enhanced DirectPath I/O. С этим улучшением предприятия смогут использовать такие расширенные возможности, как NVIDIA GPUDirect RDMA и GPUDirect Storage, для высокоскоростного обучения AI-моделей на нескольких хостах и передачи данных, что особенно важно для требовательных Gen AI-нагрузок.

3. Упрощение вывода моделей в эксплуатацию

Новые возможности в этой категории помогают предприятиям снижать сложность перевода моделей в production.

• AI Metrics Observability Dashboard.

По мере масштабирования корпоративных AI-сред ограниченная видимость производительности моделей и агентов, а также факторов затрат мешает командам выявлять неэффективность, ведет к росту расходов на инфраструктуру и снижает производительность приложений. Чтобы решить эти проблемы, выпускается AI Metrics Observability Dashboard, который будет показывать важные AI-метрики.

Улучшенная видимость AI-метрик позволит специалистам по data science и MLOps выявлять узкие места, оптимизировать распределение ресурсов, повышать throughput и производительность.

Рассмотрим некоторые AI-метрики, которые будут доступны:

Метрики моделей. Эти метрики помогут предприятиям отслеживать продуктивность, скорость, задержку и другие параметры, предоставляя детальное представление о моделях. Будут доступны такие показатели, как Cache Utilization, Tokens generated per request, Token throughput, Time to first token (TFFT), End-to-end (E2E) request latency и другие.

Метрики использования GPU. Также будут доступны GPU-метрики, включая Utilization, Temperature, Power Usage, Memory Temperature, Memory Clock и другие.

Примечание: для этих AI Metrics dashboards предприятиям необходимо развернуть Grafana.

• CPU-Based Inferencing. VCF Private AI Services теперь поддерживает CPU-based inferencing в дополнение к GPU-развертываниям благодаря интеграции Model Runtime с inference-движком Llama.cpp. На базе Llama.cpp, одного из ведущих open source inference-движков с широкой поддержкой сообщества, клиенты также получат доступ к большому набору моделей с day-zero-поддержкой от ведущих поставщиков, включая Google, OpenAI и других. Это улучшение снижает TCO, позволяя предприятиям развертывать менее ресурсоемкие среды для тестирования, proof-of-concept-инициатив или AI-приложений с минимальными требованиями к GPU либо без них.

Инфраструктурные команды сталкиваются с парадоксом: среды становятся все сложнее, а бюджеты и численность персонала остаются прежними. VMware Cloud Foundation (VCF) 9.1 призвана ответить на эту проблему инновациями, которые повышают эффективность, ускоряют доставку приложений и усиливают киберустойчивость, сохраняя при этом простоту эксплуатации. За последние несколько лет разговор об инфраструктуре изменился. Вопрос уже не только в том, где выполняются рабочие нагрузки, но и в том...

Медленная работа приложений и простои серьезно влияют на удовлетворенность клиентов, вызывают перебои в бизнес-процессах и могут отражаться на выручке. Когда критически важное приложение дает сбой в сложной распределенной среде, главная трудность заключается в том, чтобы быстро определить первопричину. Во время инцидентов высокой важности ИТ-команды оказываются в ситуационных комнатах для диагностики, где снова и снова возникает один и тот же вопрос: проблема находится в базовой инфраструктуре или в самом приложении?

При традиционном подходе сетевые, инфраструктурные и DevOps-команды вынуждены работать изолированно. Они используют разные инструменты и разрозненные наборы данных, не имея сквозной видимости. В результате возникает изматывающий цикл обмена сообщениями туда и обратно. Поиск первопричины превращается в тяжелый и медленный процесс, который занимает дни, а иногда и недели. Устаревшие балансировщики нагрузки, хотя и видят транзакции как со стороны клиента, так и со стороны сервисов, способны предоставлять только фрагментированные метрики.

Как Avi ускоряет диагностику с помощью App Health Score

Программно-определяемая архитектура балансировки нагрузки Avi является основой его аналитического преимущества. Avi собирает полную телеметрию на уровне транзакций по каждому потоку и показывает ее в единой панели управления. Благодаря этому разрозненные команды получают доступ к одной и той же сквозной аналитике задержек приложения на стороне клиента, сервера и самого приложения. Все участники могут быстро и точно определить первопричину узких мест производительности или угроз безопасности. Рассмотрим подробнее.

Сокращение Mean Time to Innocence (MTTI) за счет детальной аналитики:

Avi Analytics сводит данные о производительности приложений в понятные оценки здоровья от 0 до 100. Avi App Health Score дает комплексную оценку общего состояния приложения или виртуального сервиса, объединяя показатели производительности, доступности ресурсов, аномального поведения и факторов риска безопасности. Эти оценки дают администраторам практические подсказки и позволяют быстро находить проблемы прямо на панели управления. Например, желтая оценка 72 для «confluence prod» сразу указывает на деградацию сервиса из-за базовых ресурсов и подсвечивает критические проблемы вместе с релевантной диагностической информацией.

Кроме того, Avi Analytics существенно сокращает MTTI, предоставляя детальную видимость каждой транзакции приложения. Централизация этих метрик в единой панели помогает кросс-функциональным командам сразу понять, что задержка 75 мс возникает в приложении, а не в сети или на стороне клиента. Такой подход на основе данных сокращает длительный триаж и позволяет организациям с высокой точностью определить конкретный источник проблем производительности.

Повышение устойчивости приложений благодаря встроенной веб-безопасности:

Интегрируя сведения о безопасности непосредственно в App Health Score, Avi улучшает защиту приложений за счет встроенного web application firewall (WAF). Аналитика платформы в реальном времени выявляет частые ошибки соединений и отмечает сложные веб-атаки, включая DDoS-атаки: от обнаружения до автоматического смягчения последствий проходят минуты. В результате устойчивость приложений повышается, а высокая доступность и производительность сохраняются даже при большой нагрузке или целевых веб-угрозах.

Минимизация простоя приложений за счет выявления временных проблем:

Avi ускоряет анализ первопричин, используя глубокую историческую аналитику и избавляя команды от необходимости ждать, пока периодическая проблема повторится. Традиционным аппаратным балансировщикам нагрузки почти невозможно находить временные аномалии уровня «иголка в стоге сена», тогда как подробные журналы транзакций Avi позволяют инженерам переходить к конкретным IP-адресам серверов пула и выявлять исчерпание ресурсов виртуальных машин, то есть базовую проблему на стороне приложения.

Преимущество Avi Analytics: аналитика задержек приложений

Устаревшие балансировщики нагрузки уже не соответствуют требованиям современных приложений к производительности, гибкости и масштабируемости. Диагностика проблем производительности приложений стала реактивным и утомительным процессом. Avi собирает аналитику прямо из трафика и предоставляет единый «источник истины», который сокращает длительный операционный триаж между сетевыми, безопасностными и прикладными командами.

Программно-определяемая архитектура: Avi обеспечивает глубокую видимость в реальном времени, разделяя централизованную плоскость управления и распределенную плоскость данных. Avi развертывается как виртуальные машины рядом с вычислительной инфраструктурой. Он собирает детальную телеметрию из потока трафика и дает комплексную аналитику со сквозной видимостью из одной консоли, чтобы ускорять диагностику, автоматизировать масштабирование и заранее поддерживать высокую производительность приложений.

Полнота данных и охвата: Avi Controller непрерывно агрегирует более 700 метрик производительности из распределенных балансировщиков нагрузки. Используя высокопроизводительные вычислительные ресурсы, Avi обрабатывает крупное озеро телеметрических данных и применяет расширенные ML/AI-выводы для анализа паттернов и аномалий. Avi Analytics преобразует инфраструктурные данные в практические сведения о приложениях, позволяя ИТ-командам перейти от реактивного устранения неполадок к проактивной оптимизации.

Контекст VCF без сложной настройки: Avi глубоко и нативно интегрируется с частным облаком VCF. Благодаря контексту рабочих нагрузок VCF Avi обеспечивает согласованную видимость для виртуальных машин и контейнеров. Такая контекстная осведомленность связывает доставку и безопасность приложений с инфраструктурой, уменьшает слепые зоны и упрощает балансировку нагрузки в VCF.

Как крупная финансовая организация сократила количество заявок на 90%

Сетевые команды одной очень крупной финансовой организации до внедрения Avi Analytics постоянно были перегружены большим накопившимся объемом заявок на диагностику приложений. Ограниченная видимость, которую давали устаревшие балансировщики нагрузки, приводила к тому, что все проблемы приложений направлялись сетевым командам, даже если сеть не была их причиной. Это создавало серьезное узкое место: операционные специалисты обрабатывали почти все заявки.

После развертывания Avi Analytics организация предоставила более чем 50 DevOps-командам прямой доступ к единой аналитической панели. Команды получили практические сведения по более чем 90 000 виртуальных IP-адресов и смогли самостоятельно диагностировать, находится ли причина проблемы в приложении или в сети.

Переход к современной балансировке нагрузки на основе аналитики привел к резкому сокращению количества заявок, связанных с приложениями, которые попадали в сетевую команду: их стало меньше на 90%. В результате операционные специалисты смогли перераспределить ресурсы с обработки заявок на более ценные стратегические проекты, что показывает явное преимущество такого подхода по сравнению с традиционной балансировкой нагрузки.

Посмотреть Avi Analytics в действии

Ниже представлено подробное демо панели Avi Analytics в работе.

Развёртывание Kubernetes в производственной среде требует не просто установки кластера — необходимо с самого начала принять правильные архитектурные решения, от которых будут зависеть масштабируемость, доступность и управляемость платформы. Вебинар специалистов Broadcom Professional Services и MomentumAI посвящён ключевым принципам проектирования VMware vSphere Kubernetes Service (VKS) поверх VMware Cloud Foundation (VCF). Докладчики — Vijay Appani, Solution Architect компании Broadcom, и Caleb Washburn, CTO и основатель MomentumAI — рассматривают проверенные шаблоны проектирования, которые их команды применяют в реальных enterprise-проектах.

Что такое VKS и зачем запускать Kubernetes на VCF

VMware vSphere Kubernetes Service (VKS) — это встроенный механизм запуска Kubernetes на платформе vSphere, интегрированный непосредственно в VMware Cloud Foundation. В отличие от сторонних дистрибутивов, VKS использует подтверждённую CNCF версию Kubernetes и глубоко интегрирован с инфраструктурными компонентами VCF: вычислительным слоем (vSphere), сетью (NSX) и хранилищем (vSAN). Это позволяет организациям строить современную private cloud-платформу, избегая «лоскутных» решений и накапливаемого технического долга.

Ключевая идея заключается в том, что VCF предоставляет единую платформу, объединяющую ресурсы compute, network и storage в согласованный операционный слой. Kubernetes в таком окружении получает доступ к корпоративным политикам хранения, сетевой изоляции на уровне неймспейсов и интеграции с порталом самообслуживания VCF Automation — всё это без необходимости разворачивать и поддерживать внешние инструменты.

Три модели развёртывания Supervisor-кластера

Центральным компонентом VKS является Supervisor-кластер — уровень управления Kubernetes, развёртываемый поверх рабочего домена VCF. Существует три основные топологии его размещения, и выбор между ними определяет поведение платформы при сбоях, требования к ресурсам и сложность эксплуатации.

Модель 1: Single Cluster. Supervisor-кластер и рабочие нагрузки размещаются в одном vSphere-кластере. Это наиболее простой с точки зрения конфигурации вариант. Он подходит для начального знакомства с платформой или сред разработчиков, однако не обеспечивает разделения плоскости управления и плоскости данных. При сбое кластера теряется и управление, и рабочие нагрузки.

Модель 2: Multi-Cluster с разделёнными зонами. Supervisor-контрольная плоскость развёртывается в отдельном управляющем домене, а рабочие нагрузки — в выделенных рабочих доменах. Такое разделение обеспечивает независимость управляющего слоя от прикладного, что принципиально важно для инфраструктуры среднего масштаба. Недостатком является необходимость большего числа хостов и более сложная настройка сети и зон.

Модель 3: vSphere Zones (рекомендуется для enterprise). Виртуальные машины управляющей плоскости Supervisor-кластера распределяются по трём vSphere Zones — логическим группам, каждая из которых соответствует отдельному физическому кластеру. Рабочие нагрузки могут совместно использовать те же три зоны или размещаться в выделенных. Платформа выдерживает полный отказ одной зоны без потери доступности — ни управляющий слой, ни приложения не затрагиваются. Данная модель рекомендуется для крупных enterprise-развёртываний, требующих гарантий высокой доступности на уровне инфраструктуры.

Сетевые опции: NSX или VDS

При настройке сети для VKS на VCF доступны два варианта: NSX и vSphere Distributed Switch (VDS). Выбор между ними оказывает существенное влияние на функциональность платформы и возможности автоматизации.

NSX является рекомендованным выбором для любого нового (greenfield) развёртывания VCF. Overlay-сеть на основе Geneve/VXLAN обеспечивает полную изоляцию на уровне неймспейсов, встроенный распределённый файрвол, встроенный балансировщик нагрузки уровней L4 и L7 (NSX Advanced Load Balancer / AVI), а также глубокую интеграцию с VCF Automation. Именно NSX позволяет реализовать портал самообслуживания, где разработчики и команды самостоятельно запрашивают ресурсы, не взаимодействуя напрямую с vSphere-администраторами.

VDS применяется в случаях, когда NSX не может быть развёрнут — например, при модернизации существующей инфраструктуры или при строгих ограничениях лицензирования. VDS поддерживает базовые возможности VKS, однако не поддерживает VCF Automation, overlay-сети и встроенный балансировщик нагрузки. При использовании VDS в производственной среде потребуется внешний балансировщик, что добавляет операционную сложность.

Отдельно подчёркивается, что если требования к приложению предполагают L4 или L7 балансировку, использование выделенного балансировщика нагрузки является обязательным — независимо от выбранного сетевого варианта.

Хранилище: vSAN, политики и управление томами

Хранилище в архитектуре VKS разделяется на два типа: эфемерное (ephemeral) и постоянное (persistent). Эфемерное хранилище используется для дисков самих узлов Kubernetes (Control Plane VMs и Worker Nodes) и временных томов Pod'ов. Оно берётся из основного или дополнительного хранилища рабочего домена и настраивается при активации Supervisor-кластера.

Постоянные тома (Persistent Volumes, PV) предназначены для stateful-приложений — баз данных, очередей сообщений, систем хранения состояния. Доступ к постоянному хранилищу управляется через Storage Policies — политики хранения vSAN, которые администратор создаёт в vCenter. Политики описывают параметры производительности, доступности (RAID-1, RAID-5/6) и шифрования. Каждый арендатор (tenant) в мультитенантной конфигурации получает доступ только к тем политикам хранения, которые ему явно назначены.

Если арендатору не назначена ни одна storage policy, он не сможет создавать Persistent Volume Claims (PVC) — это удобный механизм ограничения: организации могут предоставлять namespace без прав на stateful-хранение там, где это нежелательно. Поддерживаются режимы доступа RWO (ReadWriteOnce) и RWX (ReadWriteMany) — последний обычно требует дополнительных компонентов типа vSAN File Services или внешних NFS-решений.

Мультитенантность и интеграция с VCF Automation

Одним из ключевых преимуществ VKS на VCF является встроенная поддержка мультитенантности через механизм namespace и интеграцию с VCF Automation. Каждый неймспейс представляет собой изолированную рабочую область, которой могут быть назначены: квоты на CPU и RAM, доступные storage policies, сетевые профили NSX, а также права доступа пользователей или групп из Active Directory / LDAP.

VCF Automation предоставляет портал самообслуживания, через который подразделения и команды разработчиков могут самостоятельно запрашивать Kubernetes namespace, инициировать развёртывание приложений и управлять ресурсами — без участия администратора vSphere. Платформа автоматически создаёт необходимые ресурсы: сетевые сегменты NSX, политики хранения, RBAC-права. Это, по словам авторов вебинара, является «новейшим и наиболее зрелым способом организации современного private cloud».

Рекомендуется начинать с NSX в качестве сетевого стека при любом новом greenfield-развёртывании VCF именно потому, что VCF Automation поддерживает только NSX, и без него модель самообслуживания недоступна.

Рекомендации по проектированию production-платформы

По итогам вебинара сформулированы следующие практические рекомендации для команд, проектирующих VKS на VCF в производственной среде:

• Используйте топологию vSphere Zones для любого развёртывания с требованиями к высокой доступности — она обеспечивает автоматический failover при отказе целого кластера без вмешательства администратора.
• Выбирайте NSX как сетевой стек при greenfield-развёртывании — только с NSX доступна полная интеграция с VCF Automation и портал самообслуживания.
• Планируйте storage policies заранее: определите требования к производительности и отказоустойчивости для разных классов рабочих нагрузок ещё до запуска первых неймспейсов.
• Разграничивайте доступ к хранилищу на уровне арендаторов — не назначайте storage policies тем неймспейсам, которым stateful-хранение не нужно.
• Если среда требует L4/L7 балансировки, включайте NSX Advanced Load Balancer (AVI) в архитектуру с самого начала — добавить его позднее значительно сложнее.
• Не смешивайте управляющую и рабочую плоскости в одном кластере для производственной среды: выделяйте отдельный рабочий домен для приложений, даже если это требует дополнительных хостов.

Вопросы и ответы: ключевые моменты

В ходе сессии вопросов и ответов слушателей интересовали несколько практических аспектов. На вопрос о поддержке собственных сервисов поверх VKS ответ был однозначным: технически это возможно, однако рекомендуется использовать интегрированный стек — vSAN, NSX и VCF Automation — поскольку именно на нём строится поддержка и будущее развитие платформы.

На вопрос об источниках эфемерного хранилища пояснялось, что при активации Supervisor-кластера администратор указывает datastore, из которого берётся эфемерное хранилище для узлов Kubernetes и временных томов Pod'ов. Это может быть как vSAN, так и дополнительное (supplemental) хранилище рабочего домена.

Относительно нестандартных конфигураций — в частности, развёртывания VKS поверх существующей vSphere-среды без полного стека VCF — авторы отметили, что такие варианты существуют, но лишены ключевых преимуществ интегрированной платформы: автоматизации, самообслуживания и единого управления жизненным циклом.

Итог

VMware vSphere Kubernetes Service на VMware Cloud Foundation представляет собой зрелую enterprise-платформу для запуска production-Kubernetes с полной интеграцией в корпоративную инфраструктуру. Правильный выбор топологии Supervisor-кластера, сетевого стека и модели хранения на этапе проектирования определяет, насколько легко платформа будет масштабироваться и насколько просто её будет эксплуатировать в долгосрочной перспективе. Ознакомиться с предстоящими вебинарами серии VCF можно по ссылке go-vmware.broadcom.com/VCFWebinars.

В частном облаке на базе VMware Cloud Foundation (VCF) идентификация — это первый рубеж защиты. Доступ к vCenter, NSX, SDDC Manager и VCF Operations осуществляется через корпоративного провайдера идентификации, а сетевые политики привязываются к конкретным пользователям и сервисам. Всю тему «безопасность идентификации в VCF» удобно разбить на три слоя...

Независимое исследование, проведённое компанией Principled Technologies, сравнило плотность Kubernetes-подов и скорость их готовности в двух средах: VMware Cloud Foundation (VCF) 9.0 с vSphere Kubernetes Service (VKS) 3.6 и Red Hat OpenShift 4.21 на bare metal. Это нагрузочное тестирование с использованием kube-burner — инструмента, разработанного Red Hat, — наглядно демонстрирует превосходство VCF по масштабируемости и задержкам при запуске Kubernetes в корпоративной среде.

Что такое плотность подов Kubernetes

По определению CNCF, под — наименьшая единица развёртывания контейнеризованного приложения. Каждый под содержит один экземпляр приложения с одним или несколькими контейнерами, совместно использующими вычислительные ресурсы, хранилище и сеть. Плотность подов — это количество подов, которые узел способен поддерживать при сохранении стабильной работы.

Ключевые результаты

Плотность подов: vSphere Kubernetes Service (VKS) поддержал 42 000 Kubernetes-подов до достижения пределов стабильности. Red Hat OpenShift на bare metal на идентичном оборудовании смог поддержать лишь 7 400 подов. Таким образом, VCF 9.0 обеспечил в 5,6 раза больше подов на узел/хост, чем Red Hat OpenShift, при использовании инструмента kube-burner.

Скорость готовности подов: в среднем VCF 9.0 продемонстрировал задержку в 4,9 раза ниже, чем Red Hat OpenShift, при тестировании инструментом kube-burner. На уровне 99-го процентиля vSphere Kubernetes Service (VKS) оказался быстрее в 22,5 раза при одновременном поддержании почти пятикратно большего количества подов.

Методология тестирования

Оборудование: четыре сервера Dell PowerEdge R640 с идентичными процессорами, объёмом памяти и дисковой подсистемой на обеих платформах.

Инструмент тестирования: Kube-burner — открытый инструмент CNCF, разработанный преимущественно Red Hat, предназначенный для нагрузочного тестирования и оценки масштабируемости Kubernetes-кластеров.

Метод: инструмент kube-burner постепенно увеличивал количество подов в каждой среде вплоть до достижения максимальной стабильной плотности — точки, за которой дополнительные поды приводят к деградации производительности или нестабильности кластера.

Характер отказов:

• Red Hat OpenShift: при превышении порогового количества подов рабочие узлы начинали переходить в состояние «Not Ready», что приводило к завершению работы подов и нестабильности кластера.
• VCF 9.0: масштабирование продолжалось без нестабильности узлов; ограничением стало лишь приближение к уровням потребления памяти, влияющим на производительность.

Полный отчёт доступен по ссылке: Run more Kubernetes pods and applications on VMware Cloud Foundation 9.0 with VMware vSphere Kubernetes Service. Подробное описание методологии — в разделе detailed science behind this report.

Компания «Базис», работающая на российском рынке программных решений для управления динамической инфраструктурой, сообщила о выходе платформы серверной виртуализации Basis Dynamix Enterprise версии 4.5.

В новом релизе расширены возможности экосистемы за счёт более тесной интеграции с системой управления программно-определяемыми сетями Basis SDN, улучшена совместимость с отечественными системами хранения данных, а также добавлены инструменты для повышения производительности и автоматизации управления ИТ-инфраструктурой. Всего версия 4.5 включает более 90 доработок и нововведений.

Расширение поддержки отечественных систем хранения данных

Одним из ключевых направлений развития версии 4.5.0 стало расширение поддержки российских СХД. В частности, добавлена работа с системой хранения uStor, включая полный набор операций: создание и управление дисками, работу с образами и снапшотами, а также презентацию и депрезентацию дисков вычислительным узлам.

Кроме того, реализована поддержка СХД Yadro Tatlin.Unified с версией ПО 3.2, при этом сохранена обратная совместимость с предыдущими версиями прошивки Tatlin. Это даёт заказчикам больше гибкости при выборе оборудования для построения импортонезависимой инфраструктуры и упрощает взаимодействие с ним через платформу.

Эффективное использование дискового пространства

В версии 4.5 внедрена поддержка unmap для дисков виртуальных машин. Теперь при удалении файлов внутри виртуальной машины освобождённое пространство не только помечается как свободное в гостевой системе, но и возвращается обратно в СХД. Это обеспечивает более эффективное использование дисковой ёмкости, что особенно важно при большом количестве виртуальных машин и использовании thin-provisioned дисков.

Развитие интеграции с программно-определяемыми сетями

Релиз 4.5 усиливает нативную интеграцию Basis Dynamix Enterprise с решением для программно-определяемых сетей Basis SDN и расширяет сетевые возможности платформы. Например, при создании виртуальных машин появилась возможность автоматически подключать SDN-сегменты с одновременным созданием логических портов, что сокращает объём ручной настройки и упрощает работу администраторов.

Автоматизация управления узлами

В Basis Dynamix 4.5 появился механизм автоматического перевода физического узла из состояния «На обслуживании» в статус «Работает». Соответствующая настройка доступна на странице «Физические узлы» в интерфейсе системы. При этом вместе с узлом автоматически запускаются виртуальные машины, ранее закреплённые за ним на момент перевода в режим обслуживания. Функция применима как к отдельным узлам, так и к целым зонам, что упрощает эксплуатацию крупных инфраструктур.

Другие улучшения

Помимо этого, версия 4.5.0 включает ряд дополнительных улучшений, повышающих удобство администрирования:

• Механизм Watchdog, обеспечивающий автоматическое восстановление зависших виртуальных машин.
• Поддержка режима Cache Write Through, повышающего производительность дисковой подсистемы.
• Упрощённая начальная установка за счёт минимального конфигурационного файла.
• Обновление спецификации API до версии OpenAPI 3.1.0.
• Доработка модели физического узла: понятие «вычислительный узел» (stack) было упразднено, а его функциональность перенесена в сущность «физический узел» (node), что позволило упростить как модель данных, так и API платформы.
• Возможность при создании виртуальной машины, даже если она разворачивается не из образа, включать дополнительные возможности гипервизора — такие как NUMA, CPU pinning и Huge Pages.
• Возможность сделать виртуальную машину доступной только для чтения для всех пользователей.
• При создании ВМ можно задавать маску сети для интерфейсов DPDK и VFNIC, а также настраивать MTU для транковых сетей в диапазоне от 1500 до 9216.
• Можно ограничивать количество узлов, обрабатываемых одновременно, и при этом сбой на одном узле не прерывает общий процесс.
• После первичной установки реализовано автоматическое обновление API-ключа для служебного пользователя.

Комментарий разработчика

«Одной из важнейших задач в рамках развития нашей флагманской платформы Basis Dynamix Enterprise является поддержание её совместимости с актуальным инфраструктурным оборудованием и ПО. Это касается в том числе и нашего собственного решения для организации программно-определяемых сетей Basis SDN, которое успешно работает в тестовых средах заказчиков и быстро развивается с учётом их пожеланий. Нашей целью является не просто поддержка отечественных систем хранения данных, инструментов резервного копирования или других решений. Мы хотим дать заказчику возможность построить на базе Basis Dynamix Enterprise полностью импортонезависимую динамическую ИТ-инфраструктуру, не ограничивая его при этом в выборе поставщиков "железа" или программных продуктов»

— Дмитрий Сорокин, технический директор компании «Базис».

Функция vSphere Configuration Profiles, впервые представленная в VMware vSphere 8.0, позволяет администраторам VMware Cloud Foundation управлять конфигурацией хостов ESX на уровне кластера. В данном материале рассматривается, чем эта функция отличается от Host Profiles, и как выполнить переход с Host Profiles на vSphere Configuration Profiles в vSphere 9.

Примечание: скриншоты и описанные шаги основаны на vSphere 9.0.2. В более ранних или более поздних версиях отдельные элементы интерфейса или формулировки могут отличаться.

О vSphere Configuration Profiles

vSphere Configuration Profiles — новая функция, впервые появившаяся в vSphere 8.0. Она является преемником Host Profiles в части управления конфигурацией хостов ESX в масштабе. Host Profiles неудобны тем, что требуют полного описания конфигурации хоста целиком. Это создаёт избыточную нагрузку на администраторов, которым, как правило, достаточно указать лишь те изменения, которые необходимо внести в конфигурацию.

vSphere Configuration Profiles, напротив, требует от администратора только определить отклонения от конфигурации по умолчанию. Это делает конфигурационный документ удобочитаемым и значительно более управляемым.

Переход с Host Profiles

Администраторы, управляющие конфигурацией хостов ESX с помощью Host Profiles в кластере, жизненный цикл которого управляется образами vSphere Lifecycle Manager, могут перевести кластеры на использование vSphere Configuration Profiles.

Примечание: использование vSphere Configuration Profiles с кластерами под управлением базовых уровней (baselines) поддерживается в vSphere 8 U3. Однако в vSphere 9 такие кластеры больше не поддерживаются, а Host Profiles считаются устаревшими, хотя и продолжают поддерживаться. Рекомендуется использовать кластеры под управлением образов vSphere Lifecycle Manager.

Перед переходом рекомендуется убедиться, что хосты ESX соответствуют текущему Host Profile. Ниже описан процесс перехода.

Управление конфигурацией на уровне кластера

Первый шаг — включить vSphere Configuration Profiles в кластере. Для этого перейдите в Cluster > Configure > Configuration в разделе Desired State и нажмите Create Configuration. Будут запущены проверки совместимости, чтобы убедиться, что кластер может быть переведён на vSphere Configuration Profiles. На рисунке 1 показан вариант запуска vSphere Configuration Profiles в существующем кластере.

Примечание: если к кластеру прикреплён Host Profile, появится предупреждение о необходимости удалить его после завершения перехода. После перехода Host Profiles не могут быть прикреплены ни к кластеру, ни к хостам внутри него. Этот процесс можно использовать и в том случае, если Host Profiles в данный момент не применяются.

Создание конфигурации

Далее необходимо указать, каким образом конфигурация хоста ESX для vSphere Configuration Profiles должна быть импортирована. Доступны два варианта:

1. Импорт с эталонного хоста.
2. Импорт JSON-файла с желаемой конфигурацией кластера.

Поскольку выполняется переход кластера, управляемого с помощью Host Profiles, предпочтительным вариантом является IMPORT FROM REFERENCE HOST. В качестве эталонного хоста можно выбрать любой хост ESX в кластере — все хосты уже должны соответствовать используемому Host Profile.

Примечание: при импорте с эталонного хоста любые отклонения от его конфигурации будут зафиксированы как переопределения хоста. Возможно, потребуется вручную проверить конфигурацию и удалить эти переопределения, если необходима единая конфигурация для всех хостов кластера.

На рисунке 2 показаны варианты импорта. Нажмите Import.

На рисунке 3 показан выбор эталонного хоста.

После импорта нажмите Next. Процесс импорта проверяет сгенерированный документ относительно всех хостов ESX в кластере. После успешной проверки нажмите Next. На рисунке 4 показан этап проверки конфигурации.

Предварительная проверка и применение

На последнем шаге vSphere Configuration Profiles проверяет хосты ESX в кластере на соответствие желаемой конфигурации и устраняет любые отклонения, обнаруженные в ходе проверки.

Примечание: поскольку выполняется переход с кластера под управлением Host Profile, исправлений не ожидается. Ознакомьтесь с влиянием изменений конфигурации на хосты. Нажмите Finish and Apply. На рисунке 5 показан предварительный просмотр эффекта применения. Нажмите Continue.

После этого сгенерированный vSphere Configuration Profile будет установлен в качестве желаемой конфигурации кластера, а все несоответствующие хосты ESX будут приведены в соответствие. На рисунке 6 показан диалог подтверждения завершения и применения.

Функция vSphere Configuration Profiles теперь включена, и доступен просмотр заданных конфигураций. На рисунке 7 показано, что конфигурация на уровне кластера включена.

На рисунке 8 показано соответствие хостов конфигурации кластера.

На завершающем шаге необходимо отсоединить Host Profile от хостов ESX.

Итог

Управление конфигурациями ESX остаётся непростой задачей в корпоративных средах. vSphere Configuration Profiles — новая возможность, впервые представленная в vSphere 8.0, которая решает эту задачу в масштабе большой инфраструктуры.

В последнем выпуске подкаста Virtually Speaking Ли Ховард, руководитель IAM Product Management в Broadcom, рассказал, как Identity Security для VMware Cloud Foundation (VCF) обеспечивает безопасный, масштабируемый доступ с нулевым доверием в современных средах частного облака.

Этот выпуск является частью серии VCF Advanced Services, где освещаются возможности, усиливающие безопасность, соответствие требованиям и операционный контроль сверх базовой инфраструктуры.

В этом видео объясняется, почему идентификация больше не может рассматриваться как дополнительная функция безопасности. В мире Kubernetes-нагрузок, приложений, управляемых через API, систем AI и требований суверенных облаков идентификация должна быть фундаментальной.

От статической аутентификации к Zero Trust

Традиционные стратегии управления идентификацией строились вокруг служб каталогов, статических политик и базового единого входа. Эта модель работала, когда приложения были централизованы, а пользователи действовали в пределах определённых сетевых границ. Современное частное облако устроено иначе.

Пользователи распределены. Приложения контейнеризированы. Сервисы аутентифицируются друг перед другом. AI-агенты и платформы автоматизации действуют самостоятельно. В такой среде идентификация должна быть непрерывной, контекстной и учитывающей риски.

Архитектура нулевого доверия оценивает не только то, кто входит в систему, но и как, откуда и к чему именно пытается получить доступ. Безопасность идентификации становится динамической, адаптируясь к поведенческим сигналам, уровням привилегий и контексту среды. Именно здесь современные возможности IAM и PAM становятся критически важными.

IAM и PAM в VMware Cloud Foundation

Identity and Access Management (IAM) управляет аутентификацией, авторизацией и федерацией, используя такие стандарты, как SAML и OpenID Connect. В частном облаке, построенном на VMware Cloud Foundation, IAM должен быть управляемым через API и дружественным к DevOps, позволяя командам разработки интегрировать идентификацию в современные рабочие процессы без жёстких проприетарных ограничений.

Privileged Access Management (PAM) защищает наиболее чувствительный уровень среды: административный доступ и доступ уровня root. PAM обеспечивает доступ с минимально необходимыми привилегиями, хранит учётные данные в защищённых хранилищах, автоматически ротирует пароли и записывает привилегированные сессии. Это снижает риск внутренних угроз, злоупотребления учётными данными и горизонтального перемещения во время взлома.

Важно, что безопасность идентификации теперь распространяется не только на человеческих администраторов. Машинные идентификаторы, сервисные аккаунты и системы автоматизации также должны находиться под управлением. По мере роста Kubernetes-нагрузок и AI-систем управление секретами и доступом нечеловеческих субъектов становится столь же важным, как и управление входом пользователей.

Нативная для Kubernetes идентификация в частном облаке

Платформа Identity Security работает на Kubernetes внутри VMware Cloud Foundation. Такая облачно-нативная архитектура обеспечивает быстрое развертывание, автоматическое масштабирование при всплесках аутентификации и обновления без простоев.

Сервисы идентификации являются критически важными. Если аутентификация не работает, не работает ничего. Архитектура на базе Kubernetes обеспечивает устойчивость и операционную эффективность, одновременно устраняя необходимость избыточного резервирования ресурсов, характерную для устаревших систем идентификации.

Идентификация как ключевая возможность платформы

По мере того как организации пересматривают размещение нагрузок, требования суверенности и стратегии внедрения AI, идентификация становится центральным элементом архитектуры частного облака. Она должна поддерживать доступ по модели нулевого доверия, соответствие нормативным требованиям, управление машинными идентификациями и единый контроль в разных средах.

Безопасность идентификации больше не ограничивается входом в систему. Речь идёт о контроле доступа повсюду — для пользователей, приложений, сервисов и данных. И в современной среде VMware Cloud Foundation она встроена непосредственно в саму платформу.

Что дальше в серии роликов?

Этот выпуск является частью продолжающейся серии Virtually Speaking, посвящённой Advanced Services, доступным в VMware Cloud Foundation. В каждом выпуске специалисты VMware подробнее рассматривают конкретный сервис и практические результаты, которые он обеспечивает, вместе с людьми, которые ежедневно создают и внедряют эти решения.

В следующих выпусках будут освещаться сервисы, расширяющие возможности VCF за пределы базовой инфраструктуры, включая такие области, как продвинутые сети, безопасность, сервисы данных, наблюдаемость и AI. Цель этих роликов — показать, как эти возможности работают вместе, помогая организациям модернизировать инфраструктуру, защищать приложения и ускорять инновации.

Поскольку организации уделяют приоритетное внимание цифровой трансформации, они запускают смешанный набор приложений, используя как виртуальные машины, так и контейнеры для удовлетворения своих развивающихся инфраструктурных потребностей. Однако управление как традиционными, так и контейнерными приложениями создаёт сложность, операционную неэффективность и риски безопасности. Организациям необходима единая, упрощённая и безопасная платформа, которая соединит устаревшие и современные ИТ-среды.

VMware Cloud Foundation (VCF) предлагает решение — VCF предоставляет единую платформу со встроенной средой выполнения Kubernetes, которая оркестрирует управление Kubernetes, позволяя предприятиям запускать современные приложения наряду с традиционными рабочими нагрузками, а также включает сертифицированный дистрибутив Kubernetes, соответствующий upstream-стандартам. С помощью vSphere Supervisor VCF предоставляет пользователям доступ к самообслуживанию для полного набора облачных сервисов «из коробки». Это работает в составе VMware vSphere Kubernetes Service (VKS), который используется для развертывания кластеров Kubernetes и включает совместимый выпуск Kubernetes, а также стандартный пакет ключевых компонентов OSS. VCF предоставляет облачным администраторам и платформенным инженерам выбор интерфейсов, включая GUI, CLI и API, что позволяет командам работать эффективно и продуктивно, вместо того чтобы тратить время на изучение новых наборов инструментов.

VMware недавно представила ключевые улучшения в работе Kubernetes на VCF 9.0. Независимо от того, модернизируете ли вы устаревшие приложения или масштабируете современные рабочие нагрузки, VCF 9.0 предлагает единую платформу для создания и эксплуатации всех ваших рабочих нагрузок в большом масштабе — безопасно и эффективно.

Единая платформа для виртуальных машин и контейнеров

VCF предоставляет единую платформу, которая поддерживает как устаревшие, так и современные рабочие нагрузки. Это позволяет организациям модернизировать все рабочие нагрузки единообразным способом с использованием последних инноваций Kubernetes.

• Единый API для развёртывания и управления виртуальными машинами и контейнерами: единый API позволяет пользователям создавать, развёртывать и управлять как виртуальными машинами, так и кластерами Kubernetes. Это упрощает автоматизацию, снижает сложности интеграции и обеспечивает единые политики и средства безопасности для всех рабочих нагрузок. Благодаря единому API платформенные инженеры могут взаимодействовать с вычислительными ресурсами единообразно, устраняя необходимость в отдельных инструментах и снижая затраты на обучение.
• Сертифицированный релиз Kubernetes, соответствующий upstream, с независимой возможностью обновления: VCF использует полностью соответствующий upstream-дистрибутив Kubernetes, сертифицированный Cloud Native Computing Foundation (CNCF). Эта сертификация подтверждает, что реализация Kubernetes в vSphere соответствует программе Kubernetes Conformance Program, которая проверяет upstream API Kubernetes, рабочие нагрузки и инструменты экосистемы. Например, после обновления до VKS 3.4 вы сможете создавать и управлять кластерами Kubernetes с использованием последнего релиза vSphere Kubernetes 1.33, синхронизированного с последним релизом сообщества.

• Поддержка N-2 версий Kubernetes для гибкого развертывания: VKS поддерживает текущий релиз Kubernetes и две предыдущие основные версии. Это означает, что VKS обеспечивает совместимость сразу с тремя версиями Kubernetes в любой момент времени, что позволяет различным корпоративным командам использовать ту версию, которая необходима их приложениям, а также иметь контроль и гибкость для обновления в собственном темпе.

Упрощённые и эффективные операции

VCF снижает операционную сложность, повышает гибкость управления и позволяет командам оптимизировать распределение ресурсов между различными средами.

• Самообслуживание для доступа к облачным сервисам с управлением и контролем: благодаря модели доступа на основе ролей платформенные инженеры могут использовать возможности самообслуживания для выделения инфраструктурных ресурсов (вычислительные, хранилища и сети) и набора расширенных облачных сервисов в vSphere Supervisor, таких как VM Service, Network Services и Image Registry, по требованию, в то время как облачные администраторы сохраняют управление и контроль с помощью политик и квот ресурсов. Доступ по модели самообслуживания также поддерживает multi-tenancy с изолированными средами для разных команд и проектов.

• Независимое обновление vSphere Supervisor: VMware Cloud Foundation 9.0 предоставляет облачным администраторам дополнительную гибкость, позволяя обновлять vSphere Supervisor независимо от обновления vCenter. Благодаря асинхронным обновлениям снижается операционная сложность и обеспечивается большая гибкость для ИТ-команд в поддержании актуальности сред Kubernetes при сохранении стабильности всей инфраструктуры.
• Автомасштабирование кластеров Kubernetes: улучшения автомасштабирования позволяют динамически изменять количество рабочих узлов на основе метрик в реальном времени, обеспечивая как производительность, так и эффективность. Благодаря поддержке возможностей scale-down-to-zero и scale-up-from-zero кластеры могут автоматически уменьшаться до нуля рабочих узлов в периоды простоя и бесшовно масштабироваться вверх при возобновлении нагрузки. Такая масштабируемость по требованию оптимизирует использование инфраструктуры, снижает операционные затраты и обеспечивает выделение ресурсов только тогда, когда это необходимо.
• Workload zones для оптимизации распределения ресурсов: VCF 9.0 вводит повышенную гибкость благодаря зонам рабочих нагрузок (workload zones), позволяя облачным администраторам определять и управлять ими независимо, чтобы лучше согласовывать инфраструктурные ресурсы с требованиями рабочих нагрузок. vSphere Namespaces поддерживают как однозонные, так и многозонные конфигурации, что упрощает удовлетворение различных требований высокой доступности и сценариев аварийного восстановления. Облачные администраторы также могут расширять инфраструктуру частного облака, добавляя специализированные зоны, например выделяя ресурсы для нагрузок с интенсивным использованием GPU, что обеспечивает больший контроль, оптимизированное использование ресурсов и повышенную гибкость для различных развертываний.
• Интеграция управления кластерами VKS: управление кластерами VKS позволяет облачным администраторам эффективно управлять кластерами и группами кластеров в различных средах. Благодаря встроенным возможностям, таким как управление несколькими кластерами на уровне всей инфраструктуры (fleet-wide multicluster management) и детализированный контроль доступа, команды могут ускорить развертывание, снизить операционную сложность и обеспечить единообразную конфигурацию. Такой унифицированный подход упрощает операции Day 2 и усиливает управление и контроль всей инфраструктуры Kubernetes.

Повышенная безопасность

VCF интегрирует встроенные функции безопасности для последовательной защиты рабочих нагрузок, что позволяет организациям снижать риски и улучшать общий уровень безопасности.

• Встроенная высокая доступность и надежность: VCF обеспечивает встроенную высокую доступность и надежность не только для виртуальных машин, но и для современных рабочих нагрузок. Благодаря интеграции VKS, VCF гарантирует, что контейнеризированные приложения получают те же возможности корпоративного уровня по обеспечению отказоустойчивости, такие как vSphere HA. vSAN предоставляет политики постоянного хранения, адаптированные для stateful-нагрузок Kubernetes, а NSX обеспечивает сетевую доступность и безопасное соединение между кластерами. Благодаря унифицированному управлению жизненным циклом VCF поддерживает стабильное время безотказной работы и операционную устойчивость как для виртуальных машин, так и для контейнеров, работающих на надежной инфраструктуре.
• Интеграция Istio Service Mesh: предоставляет расширенные возможности, такие как обнаружение сервисов, безопасное взаимодействие сервисов друг с другом, маршрутизация трафика и балансировка нагрузки, а также применение политик через интегрированные инструменты наблюдаемости. Благодаря таким функциям, как ingress и egress шлюзы, внедрение сбоев (fault injection), ограничение скорости запросов (rate limiting) и поддержка архитектуры нулевого доверия (zero-trust), Istio Service Mesh позволяет платформенным командам управлять сложными средами микросервисов с прозрачностью, отказоустойчивостью и соответствием требованиям, одновременно упрощая операционные процессы между кластерами Kubernetes.

• Режим OS FIPS для соответствия требованиям: новая опция конфигурации добавляет поддержку включения режима FIPS на уровне операционной системы, обеспечивая использование только криптографических модулей, прошедших валидацию FIPS, для соответствия строгим требованиям безопасности и комплаенса. Это улучшение даёт облачным администраторам гибкость в применении режима FIPS как для Linux, так и для Windows кластеров рабочих нагрузок, приводя среды Kubernetes в соответствие с федеральными и отраслевыми стандартами безопасности при сохранении операционного контроля над уровнем безопасности.
• Расширенная поддержка: в дальнейшем VMware планирует предоставлять Extended Support для определённых версий релизов vSphere Kubernetes (VKr), делая поддержку доступной в течение 24 месяцев с момента GA. Это позволит клиентам VCF оставаться на одной минорной версии Kubernetes значительно дольше, если это необходимо. Первым релизом с расширенной поддержкой станет VKr 1.33.

Кроме этого, что еще делает VCF таким особенным для запуска контейнеризированных рабочих нагрузок? VCF делает контейнеры полноценными участниками инфраструктуры наравне с виртуальными машинами, глубоко интегрируя Kubernetes в основной стек инфраструктуры с единым управлением жизненным циклом и рассматривая контейнеризированные рабочие нагрузки с тем же операционным приоритетом, управляемостью и функциональностью, что и виртуальные машины. В VCF контейнеры запускаются внутри виртуальных машин. Такая архитектура повышает безопасность за счёт дополнительного сильного уровня изоляции между рабочими нагрузками, при этом позволяя предприятиям применять существующие инструменты безопасности, политики соответствия требованиям и контроль доступа ко всем рабочим нагрузкам.

В марте на российском рынке виртуализации серверов заметно усилился акцент на экосистемной совместимости, защищённой инфраструктуре и связке отечественного ПО с локальными аппаратными платформами. Ниже — обзор ключевых событий месяца.

Совместимость zVirt с системой доверенной загрузки «Соболь»

Одной из самых заметных мартовских новостей стало подтверждение совместимости платформы виртуализации zVirt с системой доверенной загрузки «Соболь». Для рынка это не просто технический тест, а важный сигнал о том, что отечественные платформы виртуализации всё активнее встраиваются в контур защищённой ИТ-инфраструктуры.

Практическое значение новости заключается в том, что организации из госсектора, критической инфраструктуры и компаний с повышенными требованиями к безопасности получают более предсказуемый сценарий внедрения виртуализации. Защита на этапе загрузки сервера дополняет архитектуру гипервизора и снижает риски компрометации базового уровня инфраструктуры.

В более широком контексте эта новость показывает зрелость экосистемы вокруг российских платформ виртуализации: заказчику уже недостаточно просто гипервизора, ему нужен связанный стек из виртуализации, средств защиты и поддержки регуляторных требований.

Sharx Base расширяет аппаратную совместимость через интеграцию с серверами Trinity

Другой важный сюжет марта связан с платформой Sharx Base и её совместимостью с серверами Trinity. Подобные новости на первый взгляд могут выглядеть как обычные интеграционные объявления, но для рынка импортозамещения они имеют стратегическое значение.

Сегодня заказчику нужен не отдельный программный продукт, а работоспособный и подтверждённый стек: сервер, слой виртуализации, система хранения и понятная схема поддержки. Именно поэтому новости о сертифицированной или подтверждённой совместимости привлекают внимание значительно сильнее, чем просто функциональные обновления.

Интеграция Sharx Base с серверами Trinity показывает, что российские игроки продолжают выстраивать полноценную инфраструктурную экосистему. Это снижает барьер входа для корпоративных клиентов и делает проекты миграции с зарубежных решений менее рискованными.

Реальные внедрения: использование Helius в крупной корпоративной инфраструктуре

Сильный информационный эффект в марте дали новости о практическом внедрении российских решений виртуализации в крупных инфраструктурных проектах. В этом контексте особое внимание привлекло использование Helius в составе геораспределённого вычислительного кластера у НМТП.

Такие кейсы важны потому, что рынок виртуализации давно вышел из стадии обсуждения возможностей на уровне презентаций. Для корпоративных заказчиков решающим аргументом становится подтверждение того, что отечественная платформа выдерживает промышленную эксплуатацию, масштабирование и работу в распределённой среде.

Появление подобных внедрений усиливает доверие к российским продуктам и служит сигналом для компаний, которые ещё находятся в фазе выбора альтернатив зарубежным платформам. Чем больше примеров работающих production-сценариев, тем быстрее ускоряется принятие решений на рынке.

Новые серверные платформы как фундамент для роста виртуализации

Мартовская повестка была связана не только с самим ПО виртуализации, но и с аппаратной базой, на которой эти решения будут массово разворачиваться. В этом смысле важной стала новость о включении серверов «Гравитон» в реестр Минпромторга.

Для сегмента виртуализации такие новости имеют прикладное значение. Массовое внедрение гипервизоров невозможно без понятной и доступной аппаратной платформы, которая подходит для корпоративных и государственных проектов, закупается по формальным требованиям и имеет прогнозируемый цикл поставки и поддержки.

Чем увереннее развивается российская серверная база, тем устойчивее выглядит вся экосистема виртуализации. Рынок постепенно переходит от точечных проектов к сборке полноценного импортонезависимого контура, где и программная, и аппаратная части развиваются синхронно.

Отраслевые конференции как индикатор зрелости рынка

Отдельным маркером зрелости рынка стала подготовка и проведение отраслевого мероприятия "Платформы виртуализации 2026", посвящённого российским платформам виртуализации, которое пройдет 31 марта 2026 года. Конференции в этой сфере уже выступают не витриной отдельных поставщиков, а пространством для обсуждения миграционных стратегий, реальных кейсов и динамики спроса.

Многие VMware-инфраструктуры сегодня находятся в переходной стадии: организации продолжают использовать vSphere-кластеры, но постепенно переходят к модели Software-Defined Data Center и частного облака на базе VMware Cloud Foundation (VCF). Полностью перестраивать инфраструктуру с нуля в производственной среде обычно невозможно. Там уже работают десятки или сотни виртуальных машин, поэтому перенос на новую платформу должен происходить максимально аккуратно. Именно для таких сценариев VMware предлагает механизм Brownfield-интеграции.

Этот подход позволяет смигрировать существующую инфраструктуру vSphere на VMware Cloud Foundation без переустановки среды и без миграции виртуальных машин. Подробно этот процесс рассмотрел Tarsio Moraes в своем видео:

Что такое Brownfield-апгрейд

Brownfield-подход означает интеграцию уже существующей инфраструктуры в новую платформу без полного развертывания новой среды. В VMware-экосистеме это означает, что существующий vCenter Server, кластеры ESX и запущенные виртуальные машины могут быть импортированы в VCF как отдельный Workload Domain.

Таким образом инфраструктура сохраняет текущие рабочие нагрузки, но получает централизованное управление, автоматизированное lifecycle-обновление и интеграцию сетевой платформы NSX.

Архитектура до и после интеграции

Исходная инфраструктура

Типичная среда включает vSphere 8, один или несколько кластеров ESXi, vCenter Server и систему хранения — например vSAN или внешние датасторы. Сетевая конфигурация обычно построена на распределенном коммутаторе Distributed Switch. В такой архитектуре управление вычислениями, сетью и мониторингом может осуществляться через разные инструменты.

После интеграции в VCF

После импорта инфраструктура становится частью платформы VMware Cloud Foundation. Появляется централизованное управление через компоненты VCF, а инфраструктура разделяется на management domain и workload domains. Также стоит учитывать изменения в продуктовой линейке VMware: многие функции бывшей линейки Aria теперь встроены непосредственно в VMware Cloud Foundation (как функционал модуля Operations).

Подготовка инфраструктуры

Перед запуском Brownfield-апгрейда необходимо убедиться, что инфраструктура соответствует требованиям совместимости. В первую очередь проверяются версии компонентов: vSphere, vCenter Server и ESXi (теперь он снова называется ESX). Кроме того, важно убедиться в совместимости оборудования через VMware Compatibility Guide.

Также необходимо проверить базовые инфраструктурные сервисы: DNS, NTP, доступность сетей управления и состояние датасторов. Особенно важно убедиться, что DNS корректно разрешает имена хостов ESX, vCenter и будущих узлов NSX Manager.

Подготовка среды управления

Перед импортом vSphere-среды необходимо подготовить управляющие компоненты VMware Cloud Foundation. К ним относятся VCF Fleet Management и VCF Operations. Эти сервисы отвечают за централизованное управление инфраструктурой, мониторинг и lifecycle-операции. На этом этапе стоит проверить доступность management-компонентов, валидность сертификатов и сетевую связность между сервисами управления и vCenter.

Использование VCF Import Tool

Для интеграции существующей среды используется специальный инструмент — VCF Import Tool. Он анализирует конфигурацию vSphere, выполняет проверку совместимости и подготавливает инфраструктуру к импорту. Перед запуском процесса выполняется серия pre-check проверок, которые анализируют сеть, лицензии, сертификаты, конфигурацию кластеров и параметры хранения.

Если обнаружены ошибки или предупреждения, их необходимо устранить до начала импорта.

Импорт vCenter как Workload Domain

После завершения подготовительных этапов можно приступать к импорту существующего vCenter. В интерфейсе VCF создаётся новый workload domain, после чего указываются параметры подключения к существующему vCenter. После проверки параметров запускается автоматический рабочий процесс (workflow), который выполняет регистрацию vCenter в инфраструктуре VCF.

С этого момента среда становится частью VMware Cloud Foundation.

Развертывание NSX

Следующий этап — интеграция сетевой платформы NSX. Если NSX ранее не использовался, VMware Cloud Foundation может автоматически развернуть NSX Manager cluster и подготовить хосты ESX. Если NSX уже установлен в инфраструктуре, он может быть импортирован вместе с workload domain.

Пост-апгрейд проверки

После завершения интеграции необходимо провести проверку состояния среды. Стоит убедиться, что workload domain корректно отображается в интерфейсе VCF, хосты ESX подключены, датасторы доступны, а виртуальные машины работают без ошибок.

Дополнительно рекомендуется протестировать ключевые операции виртуализации: vMotion, создание снапшота и сетевую связность между виртуальными машинами.

Итог

Brownfield-апгрейд позволяет перевести существующую инфраструктуру vSphere 8 в модель VMware Cloud Foundation 9 без полного перестроения среды. Этот подход сохраняет текущие рабочие нагрузки, централизует управление инфраструктурой и позволяет постепенно перейти к архитектуре частного облака.

Frank Denneman написал отличную статью о разделении NVIDIA Multi-Instance GPU (MIG) с учетом геометрий размещения и потерянных ёмкостей ресурсов.

Архитектура инфраструктуры ИИ

Предыдущие статьи в этой серии объясняли, как работает совместное использование GPU с разделением по времени как в средах вида same-size, так и со смешанными размерами. Они показали, что такие выборы, как профили и порядок запуска рабочих нагрузок, могут напрямую влиять на использование GPU и на то, будут ли рабочие нагрузки успешно размещены. В этой части мы рассматриваем MIG и решения по проектированию, которые влияют на успешность размещения и общее использование ресурсов.

MIG использует другой подход к совместному использованию GPU. Вместо мультиплексирования вычислительных ресурсов между рабочими нагрузками MIG разделяет GPU на аппаратные экземпляры. Каждый экземпляр получает собственные выделенные вычислительные срезы (slices) и срезы памяти.

Каждый экземпляр предоставляет три основные функции: изоляцию сбоев, индивидуальное планирование и отдельное адресное пространство. Когда требуется строгая аппаратная изоляция, MIG является правильным решением, потому что рабочие нагрузки не могут мешать друг другу, а потребление ресурсов становится предсказуемым.

Многие администраторы и операторы выбирают MIG как технологию для предоставления дробных GPU без строгого требования к жёсткой изоляции. Эта статья сосредоточена на таком сценарии использования и определяет проблемы успешного размещения и использования ресурсов, включая то, как выбор профиля напрямую определяет, будет ли ёмкость GPU полностью использована или навсегда останется потерянной.

Модель ресурсов MIG

В предыдущих статьях этой серии было показано, что ёмкость GPU определяется не только объёмом свободной памяти. Ёмкость зависит от того, как ресурсы разделены и размещены. MIG добавляет ещё один уровень ограничений размещения.

Все архитектуры GPU NVIDIA, поддерживающие MIG, включая Ampere, Hopper и Blackwell, имеют одинаковую структуру. Каждый GPU предоставляет семь вычислительных срезов и восемь срезов памяти. Профили используют оба ресурса одновременно, поэтому каждый профиль представляет собой определённую комбинацию вычислительных срезов и срезов памяти, соответствующую физической структуре GPU.

В этой статье в качестве примера используется GPU H100 с объёмом памяти 80 гигабайт. В этой конфигурации каждый срез памяти представляет десять гигабайт framebuffer-памяти. Поскольку вычислительные срезы и срезы памяти выделяются вместе, один только объём свободной памяти не определяет, может ли быть запущен новый экземпляр. Требуемые вычислительные срезы также должны быть доступны и соответствовать правильной области памяти. Таблица показывает доступные профили MIG для GPU H100-80GB:

Эти профили показывают, что использование ресурсов MIG в большинстве случаев асимметрично. Некоторые профили предлагают одинаковый объём памяти, но отличаются вычислительной мощностью. Например, и 1g.20gb, и 2g.20gb предоставляют 20 GB памяти, но требуют разного количества вычислительных срезов.

То же относится и к профилям 40 GB: 3g.40gb и 4g.40gb оба используют 40 GB памяти, но требуют разные вычислительные ресурсы.

Это несоответствие между вычислениями и памятью может приводить к результатам размещения, которые на первый взгляд не очевидны.

Потерянная ёмкость

Поскольку вычислительные и срезы памяти не всегда совпадают, некоторые ресурсы GPU могут оставаться неиспользованными, даже когда устройство выглядит полностью занятым. Возьмём самый маленький профиль MIG — 1g.10gb. Этот профиль потребляет один вычислительный срез и один срез памяти. На GPU с восемьюдесятью гигабайтами можно создать семь экземпляров, потому что GPU предоставляет семь вычислительных срезов.

GPU всё ещё имеет восемь срезов памяти. После размещения семи экземпляров 10 гигабайт памяти остаются неиспользованными, или, иначе говоря, это потерянная ёмкость. Вычислительных срезов больше не осталось, поэтому ни один другой экземпляр не может быть запущен. Такое поведение легко не заметить в диаграммах размещения MIG. Эти диаграммы показывают области размещения памяти, и семь экземпляров 1g.10gb выглядят так, будто полностью заполняют GPU. На самом деле ограничивающим фактором являются вычислительные срезы, а не память.

Геометрия размещения

Профили MIG должны соответствовать определённым областям размещения памяти внутри GPU. Профили, которые используют несколько срезов памяти, требуют непрерывной области.

Профиль 3g.40gb потребляет четыре среза памяти. На GPU с объёмом памяти 80 гигабайт это создаёт две допустимые области размещения: срезы памяти 0–3 или 4–7. nvidia-smi — это инструмент командной строки NVIDIA, устанавливаемый вместе с драйвером. Флаг mig -lgi выводит список всех активных экземпляров MIG на хосте — list GPU instances — включая профиль, из которого был создан каждый экземпляр, и его положение в схеме памяти GPU. Вывод содержит колонку placement в формате start:size, где start — это индекс первого среза памяти, который занимает экземпляр, а size — количество срезов, которые он использует.

Экземпляр 3g.40gb с размещением 4:4 начинается с среза памяти 4 и занимает четыре среза, размещаясь во второй области. Экземпляр 4g.40gb с размещением 0:4 занимает первую область — единственную область, где может быть удовлетворено его требование к вычислительным ресурсам. Однако по мере размещения на GPU двух профилей 3g.40gb один вычислительный экземпляр оказывается потерянным.

Важно отметить — и профили 40gb хорошо это показывают — что MIG вводит две области: одну с четырьмя выровненными вычислительными и память-срезами и другую с тремя. Правила размещения MIG требуют, чтобы вычислительные и память-срезы начинались с одной позиции, но они не обязаны заканчиваться одновременно.

Хорошим примером этого является профиль 4g.40gb. Он может быть размещён только начиная с среза памяти 0 и, таким образом, напрямую выравнивается с вычислительным срезом 0. Фрэнк работал с системой Dell PowerEdge XE9680 HGX с восемью GPU H100 80 GB, семь из которых были пустыми.

Когда Фрэнк включил семь виртуальных машин с профилем 4g.40gb, каждая ВМ была размещена в первой области размещения (0–4) GPU H100. Последние четыре среза памяти каждого GPU всё ещё оставались свободными, но в этих областях есть только три вычислительных среза, поэтому разместить там ещё одну ВМ с профилем 4g.40gb невозможно.

Однако можно включить виртуальные машины с профилем vGPU 3g.40gb. Как показано на скриншоте, Фрэнк запустил две ВМ с этим профилем, и они были размещены на GPU 1 и 2.

Имейте в виду, что существующие экземпляры никогда не перестраиваются. То, как настроен GPU, определяет, что может быть запущено следующим. Это означает, что порядок запуска рабочих нагрузок имеет значение, поскольку он влияет на то, какие профили ещё могут быть развёрнуты, даже если кажется, что доступной памяти достаточно.

Поведение размещения

Как описано в части 4, vSphere не использует политики размещения GPU на уровне хоста, когда GPU работают в режиме MIG. Размещение следует тому же подходу, который используется в средах со смешанными размерами: сначала заполняется один GPU, прежде чем переходить к следующему, при этом сохраняется как можно больше вариантов размещения для будущих рабочих нагрузок. Это поведение значительно улучшилось в архитектуре Hopper, но Ampere иногда испытывает трудности с размещением более крупных профилей, потому что не всегда учитывает будущие размещения 4g40gb. (Reddit).

На хостах с более чем одним GPU рабочие нагрузки размещаются на одном GPU до тех пор, пока на этом устройстве больше нельзя разместить запрошенный профиль. Следующая рабочая нагрузка затем размещается на другом GPU. Та же идея применяется и внутри GPU: экземпляры размещаются так, чтобы сохранять максимально возможные непрерывные области, чтобы более крупные профили могли быть развёрнуты позже.

Хороший пример — профиль 3g.40gb. В тестовом кластере Фрэнк очистил семь GPU (кроме GPU 0, на котором выполнялась рабочая нагрузка разработчика) и запустил пять ВМ, каждая с профилем vGPU 3g.40gb. Как показано на скриншоте, первая ВМ была размещена на GPU 0 с placement id 4, оставляя место для будущего профиля 4g.40gb. Когда следующая ВМ была размещена с профилем 3g.40gb, менеджер vGPU выбрал GPU 1, оставив другие GPU открытыми для возможного размещения самого большого профиля — 7g.80gb. При каждом новом размещении менеджер vGPU сначала размещает первый профиль vGPU в позиции placement 4, прежде чем заполнять остальное пространство.

Обратите внимание, что Фрэнк зарегистрировал все эти ВМ на этом хосте, чтобы ограничить область тестирования. В реальных сценариях DRS, вместе с Assignable Hardware, распределяет ВМ между совместимыми хостами ESX в кластере на основе баланса кластера по CPU и памяти и доступности совместимых GPU.

Проектирование каталога профилей

Асимметричное потребление вычислительных срезов заставляет осознанно выбирать профили, которые будут доступны через портал самообслуживания, потому что профили, которые вы включаете, определяют, что пользователи могут запрашивать и насколько эффективно GPU будет использоваться со временем.

Профили 40 гигабайт хорошо демонстрируют этот компромисс. Один GPU может разместить два экземпляра 3g.40gb, но только один 4g.40gb, потому что второй потребовал бы восемь вычислительных срезов, тогда как GPU имеет только семь. Если вы предлагаете только 3g.40gb, один вычислительный срез всегда будет потерян на полностью загруженном GPU. Если вы предлагаете 4g.40gb вместе с более маленькими профилями, вы избегаете этих потерь, но рискуете получить ошибки размещения: профиль 4g.40gb может быть создан только в первой области памяти, поэтому если там уже есть другой экземпляр, размещение становится невозможным независимо от того, сколько памяти осталось.

Профили 20 гигабайт имеют ту же проблему, но в другой форме. Четыре экземпляра 2g.20gb не могут работать на одном GPU — снова требуется восемь вычислительных срезов, но доступно только семь. Если вы добавите профиль 1g.20gb как вариант, можно разместить четвёртую нагрузку на 20 гигабайт, но это увеличивает вероятность появления потерянной ёмкости по мере заполнения GPU экземплярами с небольшой вычислительной нагрузкой.

Не существует конфигурации, которая полностью устраняет это противоречие. Команды платформ должны решить, что важнее: предсказуемость размещения за счёт предложения меньшего количества профилей и более предсказуемого поведения или предложение полного набора профилей с принятием того, что пользователи иногда будут сталкиваться с неудачным размещением или что на некоторых GPU будет оставаться потерянная ёмкость.

Если строгая изоляция не требуется, смешанный режим, описанный в части 6 и части 7, полностью избегает этих ограничений. Четыре рабочие нагрузки по 20 гигабайт и две рабочие нагрузки по 40 гигабайт могут полностью использовать один GPU в средах со смешанными размерами, не оставляя вычислительную ёмкость потерянной.

Дункан Эппинг в своей статье ответил на этот вопрос. Он стал замечать, что этот вопрос возникает всё чаще: можно ли реплицировать или создавать снапшот виртуального модуля vSAN Stretched Cluster Witness для быстрого восстановления? Обычно люди задают его потому, что не могут соблюсти требование трёх площадок для vSAN Stretched Cluster. Поэтому, настроив какой-то механизм репликации с низким RPO, они пытаются снизить этот риск.

Возможно, этот вопрос возникает из-за недостаточного понимания того, какую роль выполняет Witness. Он обеспечивает механизм кворума, а этот механизм помогает определить, какая площадка получает доступ к данным в случае сетевого сбоя (ISL) между площадками хранения данных.

Так почему же виртуальное устройство Witness нельзя снапшотить или реплицировать? Дело в том, что для обеспечения механизма кворума Witness Appliance хранит witness-компонент для каждого объекта. Причём не для каждой площадки и не для каждой виртуальной машины, а для каждого объекта! То есть если у вас есть ВМ с несколькими VMDK, то для одной ВМ на Witness Appliance будет храниться несколько witness-объектов.

Этот witness-объект содержит метаданные и с помощью номера последовательности журнала (log sequence number) определяет, какой объект содержит самые актуальные данные. И вот здесь возникает проблема. Если вы откатите Witness Appliance к более раннему моменту времени, то witness-компоненты также откатятся назад и будут иметь другой номер последовательности журнала, чем ожидается. В результате vSAN не сможет сделать объект доступным для выжившей площадки или для той площадки, которая должна обладать кворумом.

Итак, краткий вывод: следует ли реплицировать или создавать снапшот Witness Appliance? Нет!

В видеоролике ниже демонстрируется процесс развертывания решения Private AI Foundation с NVIDIA с использованием мастера быстрой настройки.

Автор пошагово показывает, как запустить Foundation Quick Start, выбрать проект и соответствующее пространство имен (namespace), а также вставить клиентский конфигурационный токен, полученный от NVIDIA. В примере используется среда с подключением к интернету, поэтому дополнительные параметры, такие как офлайн-реестр или изменение расположения драйверов, настраивать не требуется.

Далее в видео подробно рассматриваются ключевые параметры развертывания:

• Выбор версии Kubernetes (или VKR).
• Указание образа виртуальной машины для задач глубокого обучения (Deep Learning VM), заранее загруженного в библиотеку контента.
• Выбор класса хранилища (storage class).
• Настройка GPU-совместимых классов ВМ (резервирование GPU).
• Выбор классов ВМ без поддержки GPU.

Также демонстрируется, что в рамках примера не активируются дополнительные сервисы VCF Data Services и не используется прокси-сервер.

После проверки всех параметров запускается процесс создания ресурсов каталога в выбранном пространстве имен. Через несколько минут новые элементы становятся доступны в разделе Build and Deploy -> Catalog, где можно увидеть созданные позиции Private AI Foundation с NVIDIA и при необходимости запросить их для дальнейшего использования.

Видео будет полезно администраторам и инженерам, занимающимся развертыванием инфраструктуры для задач искусственного интеллекта и машинного обучения в среде Kubernetes с поддержкой GPU.

Компания VMware продолжает развитие своей платформы для частных облаков — VMware Cloud Foundation (VCF) 9.0. Недавно опубликованы первые результаты производительности с использованием бенчмарка VMmark 4, выполненные на базе VCF 9.0 с встроенным программно определяемым хранилищем VMware vSAN. Этот результат стал важной вехой для оценки возможностей платформы в реальных условиях нагрузки, демонстрируя, что VCF 9.0 способна эффективно масштабировать инфраструктуру частного облака с помощью современного оборудования и передовых технологий.

Что такое VMmark 4, и зачем он нужен

VMmark 4 — это кластерный бенчмарк VMware, предназначенный для измерения производительности и масштабируемости виртуализированных сред. В отличие от синтетических тестов, VMmark моделирует реальные корпоративные рабочие нагрузки:

• базы данных
• веб-серверы
• почтовые системы
• application-серверы
• файловые сервисы

Нагрузка масштабируется в единицах tiles — каждый tile представляет собой комплекс виртуальных машин с типовым профилем предприятия. Итоговый показатель (VMmark Score) отражает способность кластера обслуживать увеличивающееся число рабочих нагрузок при сохранении SLA по производительности.

Тестовая конфигурация: ключевые компоненты

Для испытаний использовалась конфигурация, включающая новейшие аппаратные и программные компоненты:

• Программное обеспечение: VMware Cloud Foundation 9.0.1.0 .
• Система хранения: VMware vSAN 9.0 Express Storage Architecture (ESA) — all-flash кластер.
• Процессоры: AMD EPYC 9965 из серии 9005.
• Сетевые адаптеры: Broadcom NetXtreme-E Series BCM57508 200 GbE PCIe 4.0.
• NVMe-накопители: Micron 9550 SSD в составе vSAN.
• Тестирование: кластерный VMmark 4 с измерением масштаба до 15.4 tiles.

Программный стек VMware Cloud Foundation 9.0

VMware Cloud Foundation 9.0 — это интегрированная платформа, объединяющая ядро виртуализации, сетевые услуги и программно-определяемое хранилище:

• VMware vSphere 9: гипервизор корпоративного класса.
• vSAN 9 ESA: программное хранилище уровня предприятия с оптимизированной архитектурой Express Storage Architecture.
• NSX: сетевые сервисы и безопасность для виртуальной инфраструктуры.
• Operations: мониторинг, аналитика и автоматизация облачных ресурсов.

Главная цель VCF — упростить развёртывание и управление частными облаками с уровня инфраструктуры до сервисов, при этом обеспечивая масштабируемость, производительность и возможность автоматизации.

Результат тестирования

Для объективного сравнения использовалась идентичная вычислительная платформа (AMD EPYC 9965, суммарно 1536 физических ядер кластера), но две разные подсистемы хранения:

• vSAN 9.0 ESA (All-Flash, NVMe)
• Классический FC SAN (Dell PowerMax 8000)

Таблица результатов:

Интерпретация результатов:

• Tiles — это масштабируемые блоки нагрузки в VMmark 4. Каждый tile представляет набор типовых корпоративных рабочих нагрузок (Web, DB, Mail, Application Server и др.).
• Значение 15.4 tiles означает более высокий уровень масштабирования кластера.
• Итоговый показатель 12.42 — агрегированный производительный балл, учитывающий пропускную способность и latency.

Главный вывод - конфигурация с vSAN 9.0 ESA продемонстрировала:

• Большее число поддерживаемых tiles (15.4 против 14 для FC)
• Более высокий итоговый Score
• Лучшую масштабируемость без использования внешнего SAN-массива.

Это подтверждает, что современная архитектура vSAN ESA в составе VCF 9.0 способна не только конкурировать с традиционными FC-решениями, но и превосходить их при одинаковой вычислительной базе.

Заключение

Новый VMmark 4 результат, полученный на VMware Cloud Foundation 9.0 с vSAN, подтверждает:

• Высокую производительность и масштабируемость платформы.
• Превосходство программно-определяемого хранения (vSAN) над традиционными SAN в современных конфигурациях.
• Готовность VMware VCF 9.0 к использованию в масштабных частных облаках и корпоративных средах.

Для инженеров и архитекторов частных облаков это подтверждение того, что VCF 9.0 + vSAN — это не только удобная абстракция управления, но и мощная вычислительная платформа с высокими показателями эффективности.

VMware недавно опубликовала обновлённый набор технических руководств, которые приводят рекомендации в соответствие с архитектурой эпохи VMware Cloud Foundation и с новыми возможностями приложений Microsoft, включая SQL Server 2025 и Windows Server 2025.

Если вы планируете развёртывание VCF, модернизируете существующие среды, стандартизируете платформу, обновляете парк SQL Server или модернизируете инфраструктуру идентификации, мы рекомендуем ознакомиться с этими документами до того, как будет окончательно утверждён ваш следующий дизайн-воркшоп, цикл закупок или план миграции.

Руководство 1: Проектирование Microsoft SQL Server на VMware Cloud Foundation

Для многих команд решение о виртуализации SQL Server уже принято. Как говорится в руководстве: «вопрос больше не в том, виртуализировать ли SQL Server, а в том, как…». И это «как» существенно изменилось в мире VCF. Платформа стала более регламентированной, операционная модель — более стандартизированной, а поддерживающие возможности (хранилище, сеть, управление жизненным циклом, безопасность) эволюционировали с учётом развития аппаратных возможностей и операционных методик.

Обновлённое руководство предназначено для читателей, которые уже понимают как VCF, так и SQL Server. Оно ориентировано на несколько ролей: архитекторов, инженеров/администраторов и DBA.

Несколько моментов, на которые стоит обратить внимание:

• Современные рекомендации по CPU и NUMA теперь учитывают и новое поведение топологии в эпоху VCF. Руководство рассматривает «новые параметры конфигурации топологии vNUMA в VMware Cloud Foundation (VCF)» и объясняет, почему это поведение важно для крупных виртуальных машин SQL Server.
• Чёткая и обновлённая позиция по CPU hot plug в эпоху SQL Server 2025. В руководстве прямо указано: CPU Hot-Add больше не поддерживается в SQL Server 2025, и его не следует включать на таких виртуальных машинах.
• Рекомендации по хранилищу, соответствующие направлению развития VCF. Если вы оцениваете архитектурные варианты vSAN, руководство объясняет, почему vSAN Express Storage Architecture (ESA) привлекателен для заказчиков, переходящих на более современное оборудование, и подчёркивает возможности эффективности ESA, такие как глобальная дедупликация и преимущества сжатия для нагрузок баз данных.
• Пояснения по устаревающим функциям, влияющим на долгоживущие архитектуры. Если в вашей текущей архитектуре активно используются vVols, учтите, что Virtual Volumes объявлены устаревшими, начиная с VCF 9.0 и VMware vSphere Foundation 9.0 (полный отказ запланирован в будущих релизах).
• Операционная реалистичность для мобильности и обслуживания. Руководство рассматривает использование multi-NIC vMotion для снижения риска зависания (stun) при миграции крупных, потребляющих много памяти виртуальных машин SQL, а также отмечает, что VCF внедряет vMotion Notifications, чтобы помочь чувствительным к задержкам и кластер-осведомлённым приложениям безопаснее обрабатывать миграции.

Если вы принимаете решения - это тот документ, который снижает объём переработок, вызванных неожиданностями. Если вы технический специалист - это тот документ, который не позволит вам унаследовать архитектуру в стиле «it depends», которая позже приведёт к простою.

Руководство 2: Проектирование Microsoft SQL Server для высокой доступности на VMware Cloud Foundation

Второе руководство сосредоточено там, где ставки особенно высоки: корректное проектирование доступности SQL Server на VCF без смешивания устаревших предположений, неподдерживаемых конфигураций или подхода «потом исправим» в кластеризации.

Оно написано для смешанной аудитории, включая DBA, администраторов VMware, архитекторов и IT-руководителей. И в нём ясно указано, что «доступность» — это не функция, которую добавляют в конце; выбранная модель защиты должна определяться бизнес-требованиями.

Несколько особенно практичных обновлений:

• Реалии доступности SQL Server 2025, чётко сопоставленные с механизмами защиты. Руководство связывает уровни защиты с современными возможностями обеспечения доступности SQL Server, подчёркивает области, где SQL Server 2025 усиливает архитектуры на базе Availability Groups (AG), и отмечает, что Database Mirroring удалён в SQL Server 2025.
• Рекомендации по согласованию жизненного цикла, которые действительно важны для IT-руководства. Начиная с SQL Server 2025, отмечается, что более старые версии Windows Server вышли из основной поддержки, и рекомендуется использовать Windows Server 2025 или Windows Server 2022 при наличии совместимости — прямой переход к поддерживаемым и обоснованным платформам.
• Современные варианты кластеризации с общими дисками без навязывания устаревших архитектур. Руководство указывает, что в средах эпохи VCF 9 семантика общих дисков для FCI может быть реализована современными способами — подчёркивается использование Clustered VMDKs и явно обозначается движение в сторону отказа от устаревших зависимостей.
• Рекомендации по DRS anti-affinity, предотвращающие «самоорганизованные» события HA. Если узлы кластера SQL работают на одном и том же хосте ESXi «потому что так решил DRS», это не высокая доступность, а отложенный инцидент. Настройте соответствующие правила DRS, чтобы узлы кластера были физически разделены.
• Требования к vMotion Application Notification, изложенные подробно. Руководство описывает использование уведомлений приложений, включая требования, такие как актуальные VMware Tools и рекомендуемая настройка таймаутов — именно те детали, которые команды часто выясняют в условиях уже упавшей системы.
• Рекомендации по vSAN ESA, отражающие текущие возможности. Указывается направление политик ESA и отмечается глобальная дедупликация (впервые представленная в VCF 9.0) как рекомендуемая для определённых сценариев Availability Group SQL Server в пределах одного кластера vSAN.

Это то руководство, которое вы передаёте команде, когда бизнес говорит: «нам нужна более высокая доступность», — и вы хотите, чтобы ответом стало инженерно проработанное решение.

Руководство 3: Виртуализация служб домена Active Directory на VMware Cloud Foundation

Active Directory (AD) Domain Services (DS) — одна из тех служб, о которых не думают до тех пор, пока всё не перестанет работать. Обновлённое руководство по AD DS прямо признаёт это, указывая, что многие организации справедливо рассматривают AD DS как по-настоящему критичное для бизнеса приложение, поскольку аутентификация, доступ к ресурсам и бесчисленные рабочие процессы зависят от него.

Оно также напрямую обращается к сохраняющемуся рефлексу «физического контроллера домена». Благодаря развитию Windows Server и зрелым практикам VCF, в руководстве говорится, что эти улучшения теперь позволяют организациям «безопасно виртуализировать сто процентов своей инфраструктуры AD DS».

Существенно обновлены не общие рекомендации «виртуализируйте это», а современный набор функций и механизмов защиты, которые меняют подход к проектированию и защите виртуальных контроллеров домена:

• В руководстве указано, что лишь несколько усовершенствований существенно изменяют прежние рекомендации, включая Virtualization-Based Security (VBS), Secure Boot, шифрование на уровне виртуальной машины и улучшенную синхронизацию времени в гостевых ВМ — и эти изменения учтены там, где это необходимо.
• Документ явно ориентирован на несколько аудиторий (архитекторов, инженеров/администраторов и руководителей/владельцев процессов), что важно для AD DS, поскольку проектирование и эксплуатация неразделимы.
• Подчёркиваются операционные меры защиты при восстановлении после сбоев. Например, рекомендуется использовать приоритет перезапуска ВМ в vSphere HA, чтобы ключевые инфраструктурные службы запускались раньше после аварийного восстановления.
• Подробно рассматриваются механизмы обеспечения целостности в эпоху виртуализации (например, поведение VM-Generation ID), созданные специально для устранения исторических опасений, связанных со снапшотами и откатами.

Если вы модернизируете инфраструктуру идентификации, консолидируете датацентры или строите частное облако на базе VCF с сильной позицией по безопасности, этот документ обязателен к прочтению. AD DS — это не просто ещё одна рабочая нагрузка. Это сущность, от которой зависит работа всего вашего стека.

Руководство 4: Запуск Microsoft SQL Server Failover Cluster Instance на VMware vSAN платформы VMware Cloud Foundation 9

Если ваша модель обеспечения доступности по-прежнему основана на кластеризации с общими дисками — будь то из-за ограничений приложений, операционных предпочтений или необходимости сохранить модель SQL Server FCI — это руководство является практическим дополнением «как это реально работает на VCF 9» к более общим рекомендациям по HA. Это эталонная архитектура для запуска Microsoft SQL Server Failover Cluster Instance (FCI) с использованием общих дисков на базе vSAN, валидированная как для стандартного кластера vSAN, так и для сценария растянутого кластера vSAN.

Несколько моментов, на которые стоит обратить внимание:

• Нативная поддержка WSFC + общих дисков на vSAN (с подробным описанием механики). В VCF 9 «vSAN обеспечивает нативную поддержку виртуализированных Windows Server Failover Clusters (WSFC)» и «поддерживает SCSI-3 Persistent Reservations (SCSI3PR) на уровне виртуального диска» — ключевое требование для арбитража общих дисков в WSFC.
• Две настройки конфигурации, от которых зависит работоспособность общих дисков. Указывается, что общие диски должны быть подключены к контроллеру с параметром SCSI Bus Sharing, установленным в Physical, и что «режим диска для всех дисков в кластере должен быть установлен в Independent – Persistent», чтобы избежать неподдерживаемой семантики снапшотов на общих дисках.
• Операционные особенности растянутого кластера: задержки, размещение и кворум являются частью архитектуры. Рекомендуется «менее четырёх миллисекунд межсайтовой (round trip) задержки» для SQL-баз данных уровня tier-1 в растянутых кластерах vSAN, а также подчёркивается необходимость правил DRS VM/Host для разделения узлов WSFC по разным хостам.
• Также рекомендуется использовать диск-свидетель кворума, чтобы растянутый кластер сохранял доступность witness-диска при отказе сайта без остановки службы кластера FCI.
• Практический путь миграции с SAN pRDM на общие VMDK vSAN. С самого начала подчёркивается: «перед миграцией настоятельно рекомендуется создать резервную копию», и отмечается, что миграция выполняется офлайн. Описываются шаги по остановке роли кластера, выключению узлов и использованию Storage Migration для преобразования pRDM в VMDK на vSAN ± с обходным решением через PowerCLI (включая пример кода) в случае, если выбор формата диска в мастере Migrate недоступен.

Это руководство, которое вы передаёте команде, когда требование звучит как «нам нужна семантика FCI», и вы хотите получить осознанную, поддерживаемую архитектуру.

Что дальше

Если вы активно проектируете, обновляете или мигрируете инфраструктуру, рассматривайте эти руководства в контексте команд:

• Команды платформы: сначала прочитайте руководство по SQL Server, чтобы согласовать значения по умолчанию вычислений/хранилища/сети с поведением SQL.
• DBA и инженеры инфраструктуры: прочитайте руководство по HA до того, как зафиксируете модель кластеризации, стратегию хранения и модель обслуживания.
• Команды по идентификации и безопасности: прочитайте руководство по AD DS, чтобы согласовать меры настройки, восстановления и операционные процессы с современными механизмами защиты виртуализации.
• Команды, использующие (или стандартизирующие) SQL Server FCI: прочитайте руководство по FCI на vSAN, чтобы зафиксировать требования к общим дискам, позицию по политике хранения и ограничения растянутого кластера до внедрения.

Ниже приведены прямые ссылки для скачивания упомянутых документов:

• Architecting Microsoft SQL Server on VMware Cloud Foundation:
  https://www.vmware.com/docs/architecting-mssql-vcf
• Virtualizing Active Directory Domain Services on VMware Cloud Foundation:
  https://www.vmware.com/docs/active-directory-domain-services-vcf
• Architecting Microsoft SQL Server for High Availability on VMware Cloud Foundation:
  https://www.vmware.com/docs/architecting-mssql-ha-vcf
• Running Microsoft SQL Server Failover Cluster Instance on VMware vSAN with VMware Cloud Foundation 9:
  https://www.vmware.com/docs/mssql-fci-vcf-9

В современных гибридных и частных облаках большое количество данных о состоянии систем поступает из самых разных источников: систем резервного копирования, хранилищ данных, SaaS-платформ и внешних сервисов. Однако интеграция этих данных в единую платформу мониторинга часто оказывается сложной задачей. Для решения этой проблемы в составе VMware Cloud Foundation был представлен инструмент Management Pack Builder (MPB), предназначенный для расширения наблюдаемости и видимости инфраструктуры. О его бета-версии мы писали еще в 2022 году, но сейчас он уже полноценно доступен в составе VCF.

Что такое Management Pack Builder

Management Pack Builder (MPB) — это функциональность VMware Cloud Foundation, представляющая собой no-code-решение для создания пакетов управления (management packs), которые позволяют импортировать данные наблюдения из внешних источников в систему мониторинга VCF Operations. MPB выполняет роль промежуточного слоя, преобразуя данные, полученные через REST API сторонних систем, в объекты, метрики, свойства и события, понятные и используемые в экосистеме VMware Cloud Foundation.

С помощью Management Pack Builder можно:

• Подключаться к REST API внешних систем
• Создавать собственные типы объектов мониторинга
• Сопоставлять данные API с метриками и свойствами в VCF Operations
• Формировать повторно используемые пакеты управления для развертывания в разных средах

Какие задачи решает Management Pack Builder

Заполнение пробелов в мониторинге

Во многих организациях используются системы, для которых не существует готовых адаптеров мониторинга VMware. MPB позволяет интегрировать такие источники данных и устранить «слепые зоны» в наблюдаемости инфраструктуры.

Упрощение интеграции сторонних решений

Традиционная разработка адаптеров требует значительных затрат времени и ресурсов. Management Pack Builder позволяет создавать интеграции без написания кода, что существенно ускоряет процесс и снижает операционные издержки.

Централизация данных наблюдаемости

MPB помогает устранить разрозненность данных, объединяя телеметрию из различных систем в единой платформе. Это упрощает корреляцию событий, ускоряет диагностику проблем и снижает среднее время восстановления сервисов.

Масштабируемость и повторное использование

Один раз созданный пакет управления может быть экспортирован и развернут в других инсталляциях VMware Cloud Foundation, обеспечивая единый подход к мониторингу в масштабах всей организации.

Работа с нестандартными API

Management Pack Builder поддерживает гибкое сопоставление данных и может использоваться даже в случаях, когда REST API внешних систем не полностью соответствует стандартным спецификациям.

Преимущества использования MPB

Использование Management Pack Builder обеспечивает следующие преимущества:

• Быстрое подключение новых источников телеметрии
• Единая панель мониторинга в рамках VMware Cloud Foundation
• Снижение затрат на разработку и поддержку интеграций
• Возможность моделирования пользовательских объектов и метрик
• Простое распространение решений между средами

Типовой рабочий процесс в Management Pack Builder

Процесс создания пакета управления с помощью MPB включает следующие этапы:

1. Определение источника данных и необходимых конечных точек API
2. Проектирование объектной модели и связей между объектами
3. Настройка параметров сбора данных, включая аутентификацию и расписание
4. Сопоставление полей ответов API с метриками и свойствами
5. Тестирование корректности сбора и отображения данных
6. Экспорт и развертывание пакета управления в других средах

Пример использования: мониторинг задач резервного копирования

Предположим, что система резервного копирования предоставляет данные о заданиях через REST API, включая статус выполнения, продолжительность и объем обработанных данных. С помощью Management Pack Builder можно:

• Подключиться к API системы резервного копирования
• Создать новый тип объекта, представляющий задачу резервного копирования
• Определить метрики, отражающие состояние и эффективность выполнения
• Настроить дашборды и оповещения в VCF Operations
• Использовать созданный пакет управления в других кластерах

Данный процесс на примере решения Rubrik показан в видео ниже:

В результате информация о резервном копировании становится частью единой системы наблюдаемости VMware Cloud Foundation, и вам не потребуется никаких отдельных консолей для мониторинга этого процесса.

Рекомендации по эффективному использованию MPB

Для успешного применения Management Pack Builder рекомендуется:

• Начинать с минимального набора метрик и постепенно расширять модель
• Использовать стабильные и уникальные идентификаторы объектов
• Оптимизировать частоту опроса API, чтобы избежать избыточной нагрузки
• Использовать примеры и лучшие практики, опубликованные в сообществах VMware

Роль Management Pack Builder в экосистеме VMware Cloud Foundation

VMware Cloud Foundation ориентирован на обеспечение унифицированного управления, операций и наблюдаемости в гибридных и частных облаках. Management Pack Builder дополняет эту концепцию, позволяя включать в контур мониторинга любые внешние и пользовательские системы.

Это обеспечивает целостное представление о состоянии инфраструктуры и приложений, независимо от источника данных.

Заключение

Management Pack Builder является важным инструментом для расширения возможностей наблюдаемости в VMware Cloud Foundation. Он позволяет быстро и гибко интегрировать сторонние источники телеметрии, сократить затраты на разработку адаптеров и централизовать мониторинг.

Использование MPB помогает организациям получить полную и целостную картину состояния своей инфраструктуры, повышая надежность и управляемость IT-среды.

Отличные новости для сетевых инженеров и архитекторов, работающих в экосистеме VMware. Компания представила новую сертификацию VMware Certified Advanced Professional – VCAP Administrator Networking (3V0-25.25). Этот экзамен продвинутого уровня (VCAP) предназначен для подтверждения глубоких знаний и практических навыков в проектировании, развертывании и администрировании сетевых решений VMware Cloud Foundation (VCF).

Новый стандарт профессиональной экспертизы в VCF Networking

Экзамен 3V0-25.25 ориентирован на опытных ИТ-специалистов, которые работают с современными корпоративными и мультиоблачными инфраструктурами. Получение данной сертификации демонстрирует способность кандидата эффективно решать сложные сетевые задачи в рамках архитектуры VMware Cloud Foundation.

Ключевые параметры экзамена:

• Код экзамена: 3V0-25.25
• Продолжительность: 135 минут
• Количество вопросов: 60
• Проходной балл: 300
• Стоимость: 250 USD
• Язык: английский

Кому подойдет эта сертификация

Экзамен рассчитан на специалистов с уверенным опытом в корпоративных сетях и экспертизой по решению VMware NSX. Рекомендуемый профиль кандидата включает:

• 1–2 года практического опыта проектирования и администрирования решений NSX
• Не менее 2 лет работы с Enterprise-сетями
• Уверенное владение UI-, CLI- и API-ориентированными рабочими процессами VCF
• Практический опыт работы с VCF Networking и vSphere

Если вы ежедневно сталкиваетесь с проектированием и эксплуатацией сложных сетевых архитектур, этот экзамен станет логичным шагом в развитии карьеры.

Что проверяет экзамен 3V0-25.25

Основной акцент в экзамене сделан на планирование и дизайн сетевых решений VCF, с максимальной ориентацией на реальные архитектурные сценарии. Ключевые области оценки знаний включают:

• ИТ-архитектуры, технологии и стандарты - проверяется понимание архитектурных принципов, умение различать бизнес- и технические требования, а также управлять рисками и ограничениями при проектировании.
• Планирование и проектирование решений VMware - центральный блок экзамена, оценивающий способность спроектировать полноценное решение VMware Cloud Foundation с учетом доступности, управляемости, производительности, безопасности и восстановляемости.

Несмотря на то что в экзаменационном гайде указано наличие разделов без активных проверяемых целей, глубокое понимание всего жизненного цикла VCF Networking — от установки до устранения неполадок — значительно повышает шансы на успех.

Как подготовиться к экзамену

VMware рекомендует сочетать практический опыт с целенаправленным обучением. Для подготовки к экзамену доступны следующие курсы:

• VMware Cloud Foundation Networking Advanced Design
• VMware Cloud Foundation Networking Advanced Configuration
• VMware Cloud Foundation Networking Advanced Troubleshooting

Также крайне важно изучить официальную документацию VMware Cloud Foundation 9.0, актуальные release notes и технические материалы от Broadcom, чтобы быть в курсе всех возможностей и изменений платформы.

Будьте среди первых сертифицированных специалистов

Выход сертификации VMware Certified Advanced Professional – VCF Networking — значимое событие для профессионалов в области сетевых технологий. Этот статус подтверждает высокий уровень экспертизы и позволяет выделиться на фоне других специалистов, открывая новые карьерные возможности. Если вы хотите быть на передовой в индустрии и официально подтвердить свои знания в области VCF Networking — сейчас самое время сделать этот шаг.

Недавно был выпущен пакет управления vCommunity Management Pack для VCF Operations (подробнее о нем - тут), который охватывает несколько сценариев использования, включая: расширенные системные настройки хоста ESX, его пакеты и лицензирование, статус сетевых интерфейсов (NIC), расширенные параметры виртуальных машин, параметры ВМ, типы контроллеров SCSI виртуальных машин, а также службы события Windows.

Ну а на днях стал доступен для скачивания проект Hardware vCommunity Management Pack для VCF Operations, разрабатываемый инженером Broadcom Онуром Ювсевеном. Начальная версия поддерживает серверы Dell EMC PowerEdge (с использованием Redfish API на iDRAC). Он собирает десятки метрик, свойств и событий. Пакет управления включает 5 дашбордов, 8 представлений, 14 алертов и 19 симптомов (symptoms). Дашборды выглядят следующим образом.

Сам Management Pack можно скачать здесь. После загрузки он устанавливается так же, как и любой другой Management Pack. Затем необходимо создать экземпляр адаптера (или несколько, если требуется), который будет выглядеть примерно следующим образом.

Существует несколько требований:

• Файл конфигурации физических серверов — список FQDN/IP-адресов серверов Dell EMC. Файлы конфигурации можно создать в разделе Operations > Configurations > Management Pack Configurations > User Defined. Формат должен быть вот таким.
• Учётные данные iDRAC Redfish API (только чтение), а также Dell TechDirect Client ID/Secret (если требуется информация о гарантии).
• Collector/Group — необходимо использовать Cloud Proxy.
• Dell iDRAC Log Monitoring — уровень событий iDRAC, которые вы хотите собирать (или Disabled, если сбор не нужен).
• Dell Warranty Checker — переключатель проверки гарантии (Enable/Disable).
• Dell TechDirect URL — URL Dell TechDirect, к которому экземпляр адаптера будет обращаться для получения информации о гарантии.
• Maximum worker threads for data collection — максимальное количество рабочих потоков для сбора данных (по умолчанию 200).
• Maximum worker threads for ping request — максимальное количество рабочих потоков для ping-запросов (по умолчанию 100).
• Adapter Mode — режим работы адаптера: Server Monitoring или PING Only.
• Adapter Memory Limit (MB) — максимальный объём памяти, который будет использовать экземпляр адаптера.

После установки назначьте Custom Group Dell EMC Servers политике Hardware vCommunity Policy. Это включит все определения оповещений. vCommunity Management Pack создаст новый тип объекта с именем Physical Server.

MP собирает десятки метрик и свойств не только по самому серверу, но также по батареям, блокам питания, вентиляторам и другим компонентам. Кроме того, был добавлен бонусный дашборд (Dell EMC Server Details), который при желании можно использовать в качестве страницы сводной информации по физическому серверу (Physical Server Summary Page).

Чтобы настроить этот дашборд как страницу сводки физического сервера, выполните описанные здесь действия. После настройки он будет выглядеть следующим образом.

vCommunity Hardware Management Pack также включает алерты, как показано ниже:

Два ключевых свойства, которые собираются и по которым формируются оповещения — это остаточный прогнозируемый срок службы физического диска (Physical Disk Predicted Media Life Remaining) и оставшийся срок гарантии (Warranty Remaining), что позволяет администраторам заблаговременно планировать обслуживание и предотвращать проблемы.

В дальнейшем планируется расширение функциональности, включая связи с хостами ESX и поддержку дополнительных аппаратных платформ. Скачивайте и начинайте использовать уже сегодня!

Наверняка не всем из вас знаком ресурс virten.net — технический портал, посвящённый информации, новостям, руководствам и инструментам для работы с продуктами VMware и виртуализацией. Сайт предлагает полезные ресурсы как для ИТ-специалистов, так и для энтузиастов виртуализации, включая обзоры версий, документацию, таблицы сравнений и практические руководства.

Там можно найти:

• Новости и статьи о продуктах VMware (релизы, обновления, сравнения версий, технические обзоры).
• Полезные разделы по VMware vSphere, ESX, vCenter и другим продуктам, включая истории релизов, конфигурационные лимиты и различия между версиями.
• Практические инструменты и утилиты, такие как декодеры SCSI-кодов, RSS-трекер релизов (vTracker), помощь по OVF/PowerShell, события vCenter и JSON-репозиторий полезных данных.

Давайте посмотрим, что на этом сайте есть полезного для администраторов инфраструктуры VMware Cloud Foundation.

VMware Product Release Tracker (vTracker)

Эта страница содержит список продуктов, выпущенных компанией VMware. vTracker автоматически обновляется, когда на сайте vmware.com становятся доступны для загрузки новые продукты (GA — общедоступный релиз). Если вы хотите получать уведомления о выходе новых продуктов VMware, подпишитесь на RSS-ленту. Вы также можете использовать экспорт в формате JSON для создания собственного инструмента. Не стесняйтесь оставлять там комментарии, если у вас есть предложения по новым функциям.

• vTracker RSS Feed
• vTracker JSON Export
• vTracker CSV Export
• vTracker Table

Если вы просто хотите узнать, какая версия того или иного продукта VMware сейчас актуальна, самый простой способ - это посмотреть вот эту таблицу с функцией поиска:

VMware ESXi Release and Build Number History

В этом разделе представлен полный перечень релизов флагманского гипервизора VMware ESX (ранее ESXi). Все версии, выделенные жирным шрифтом, доступны для загрузки. Все патчи указаны под своими официальными названиями релизов, датой выхода и номером билда. Обратите внимание, что гипервизор ESXi доступен начиная с версии 3.5.

Если вы столкнулись с какими-либо проблемами при работе с этим сайтом или заметили отсутствие сборок, пожалуйста, свяжитесь с автором.

VMware vCenter Release and Build Number History

По аналогии с гипервизором ESX/ESXi, на этой странице доступны даты релизов и номера билдов для средства управления VMware vCenter:

Такой же список релизов есть на сайте и для VMware NSX.

PowerShell OVF Helper

Эта страница представляет собой коллекцию заранее настроенных фрагментов PowerShell-скриптов для развертывания OVF/OVA. Идея заключается в ускорении процесса развертывания, если вам необходимо устанавливать несколько виртуальных модулей, выполнять повторное развертывание из-за неверных входных данных или сохранить файл в качестве справочного примера для будущих установок.

Просто заполните подготовленные переменные так же, как вы обычно делаете это в клиенте vSphere, и запустите скрипт. Все шаблоны используют одинаковую последовательность действий и тексты подсказок из мастера развертывания. Необязательные параметры конфигурации можно закомментировать. Если у параметров есть значения по умолчанию, они уже заполнены.

VMware ESXi SCSI Sense Code Decoder

Ошибки или предупреждения SCSI в логах и интерфейсе ESX отображаются с использованием 6 кодов состояния. Эта страница преобразует эти коды, полученные от хостов ESX, в понятную для человека информацию о состоянии подсистемы хранения. В системном журнале vmkernel.log на хостах ESXi версии 5.x или 6.0 вы можете увидеть записи, подобные приведённым ниже. На странице декодера вы можете ввести нужные числа в форму и получить пояснения по сообщениям SCSI:

В этой части статей о технологии NVMe Memory Tiering (см. прошлые части тут, тут, тут, тут и тут) мы поговорим о настройке этой технологии на серверах VMware ESX инфраструктуры VCF.

На протяжении всей этой серии статей мы рассматривали важные аспекты, которые следует учитывать перед настройкой Memory Tiering, такие как проектирование, подбор размеров, совместимость, избыточность, безопасность и многое другое. Теперь пришло время применить то, чему вы научились, и оптимизировать эту функцию для вашей среды, бюджета и стратегии.

Поскольку во многих статьях подробно описаны шаги настройки, этот пост будет сосредоточен на подходе высокого уровня и будет ссылаться на предыдущие посты для конкретных разделов. Всегда полагайтесь на официальную документацию Broadcom для точных шагов настройки — официальное руководство можно найти здесь, ну а основные аспекты развертывания Memory Tiering мы описывали тут.

Шаги настройки

Технически для настройки Memory Tiering в вашей среде требуется всего два шага, но мы добавили задачи до и после настройки, чтобы обеспечить должную тщательность и проверить внедрение.

Предварительные проверки

Плотники живут по правилу «семь раз отмерь — один раз отрежь», потому что после разреза нельзя прокрутить фарш обратно. Чтобы избежать критических ошибок при настройке, мы должны сначала убедиться, что приняли правильные архитектурные решения для нашей среды.

Убедитесь, что вы ознакомились со следующим:

• Классы износа и производительности NVMe
• Избыточность и RAID-контроллеры
• Подбор размера NVMe-устройств
• Совместимость с vSAN

После того как вы приняли все эти важные решения, этап предварительных проверок включает подтверждение того, что устройства корректно отображаются на всех ESX-хостах. Вам понадобится UID каждого устройства, чтобы создать раздел, который будет использоваться Memory Tiering.

Создание разделов

Первый шаг — создание раздела для каждого NVMe-устройства. Независимо от того, разворачиваете ли вы одно устройство на хост или используете аппаратный RAID, раздел требуется на каждом логическом NVMe-устройстве.

Методы:

• ESXCLI: выполните стандартную команду esxcli (подробности тут).
• PowerShell: создайте скрипт для автоматизации процесса. Пример скрипта доступен тут, он может быть изменён под среду вашего кластера.

Частые вопросы

Вопрос: Могу ли я настроить разделы на двух устройствах без RAID на одном и том же хосте для обеспечения избыточности?
Ответ: Нет. Хотя VCF 9.0 позволяет без ошибок создавать разделы Memory Tiering на нескольких устройствах на хост, система не объединяет их и не зеркалирует данные.

Результат: Memory Tiering смонтирует только один диск, выбранный недетерминированным образом в процессе загрузки. Второй диск будет проигнорирован и не даст ни избыточности, ни увеличения ёмкости (см. будущую информацию об обновлении VCF 9.1 - там что-то может поменяться).

Включение Memory Tiering

Этот шаг активирует функцию Memory Tiering. Вы можете выполнить эту настройку через ESXCLI, PowerShell или интерфейс vCenter UI, применяя её к отдельным хостам или ко всему кластеру одновременно.

Вопрос: Требуется ли настраивать Memory Tiering на всех хостах в кластере VCF 9.0?
Ответ: Нет. У вас есть возможность выбрать конкретные хосты для Memory Tiering.

Хотя идеально, чтобы все хосты имели одинаковую конфигурацию, все понимают, что определённые ограничения ВМ могут потребовать исключений (см. тут).

Самый эффективный способ настроить Memory Tiering — использовать профили конфигурации vSphere. Это позволяет включить функцию сразу на всех ваших хостах, одновременно используя переопределения хостов для тех хостов, где вы не хотите включать её. Подробнее — тут.

Финальный шаг

Последний шаг прост: перезагрузите все хосты и выполните проверку. В VCF/VVF 9.0 перезагрузка является обязательной, чтобы эта функция вступила в силу.

Если вы используете профили конфигурации (Configuration Profiles), система автоматизирует поочерёдные перезагрузки (одна за другой), одновременно мигрируя ВМ, чтобы они оставались в сети. И если вам интересно, обеспечивает ли этот метод также доступность данных vSAN - ответ: да.

После того как все хосты снова будут онлайн, вы увидите новые элементы в интерфейсе, расположенные в разделах Advanced System Settings, на вкладке Monitor, а также Configure > Hardware > Overview > Memory.

Вы также должны увидеть, что по умолчанию объём доступной памяти увеличился в 2 раза как на уровне хоста, так и на уровне кластера. Вот это простой и недорогой способ удвоить ваш объём памяти!

В заключение: включение Memory Tiering - очень простой и понятный процесс. В качестве бонуса добавляем ссылку на актуальную лабораторную работу (Hands-on Lab), посвящённую Memory Tiering. Там вы можете выполнить настройку «от начала до конца», включая расширенные параметры, которые будут рассмотрены в следующих постах.

В этой статье мы завершаем рассказывать об итогах 2025 года в сферах серверной и настольной виртуализации на базе российских решений. Сегодня мы поговорим о том, как их функционал соотносится с таковым от ведущего мирового производителя - VMware.

Первую часть статьи можно прочитать тут, вторая - доступна здесь.

Сравнение с VMware vSphere

Как же отечественные решения выглядят на фоне VMware vSphere, многолетнего эталона в сфере виртуализации? По набору функций российские платформы стремятся обеспечить полный паритет с VMware – и во многом этого уже достигли. Однако при более глубоком сравнении выявляются отличия в зрелости, экосистеме и опыте эксплуатации.

Функциональность

Почти все базовые возможности VMware теперь доступны и в отечественных продуктах: от управления кластерами, миграции ВМ на лету и снапшотов до сетевой виртуализации и распределения нагрузки. Многие платформы прямо ориентируются на VMware при разработке. Например, SpaceVM позиционирует свои компоненты как аналоги VMware: SDN Flow = NSX, FreeGRID = NVIDIA vGPU (для Horizon), Space Dispatcher = Horizon Connection Server. ZVirt, Red, ROSA, SpaceVM – все поддерживают VMware-совместимые форматы виртуальных дисков (VMDK/OVA) и умеют импортировать ВМ из vSphere.

То есть миграция технически осуществима без кардинальной переделки ВМ. Live Migration, HA, кластеры, резервирование – эти функции стали стандартом де-факто, и российские продукты их предоставляют. Более того, появились и некоторые новые возможности, которых нет в базовом издании vSphere: например, интеграция с Kubernetes (KubeVirt) в решении Deckhouse от Flant позволяет управлять ВМ через Kubernetes API – VMware предлагает нечто подобное (vSphere with Tanzu), но это отдельно лицензируемый модуль.

Другой пример – поддержка облачных сервисов: некоторые отечественные платформы сразу рассчитаны на гибридное облако, тогда как VMware требует vCloud Suite (сейчас это часть платформы VMware Cloud Foundation, VCF). Тем не менее, зрелость функционала различается: если у VMware каждая возможность отполирована годами использования по всему миру, то у новых продуктов возможны баги или ограничения. Эксперты отмечают, что просто сравнить чекбоксы “есть функция X” – недостаточно, важна реализация. У VMware она, как правило, образцовая, а у российского аналога – может требовать ручных доработок. Например, та же миграция ВМ в российских системах работает, но иногда возникают нюансы с live migration при специфических нагрузках (что-то, что VMware давно решила).

Производительность и масштабирование

VMware vSphere славится стабильной работой кластеров до 64 узлов (в v7 – до 96 узлов) и тысяч ВМ. В принципе, и наши решения заявляют сопоставимый масштаб, но проверены они временем меньше. Как упоминалось, некоторые продукты испытывали сложности уже на 50+ хостах. Тем не менее, для 90% типовых инсталляций (до нескольких десятков серверов) разницы в масштабируемости не будет. По производительности ВМ – разница тоже минимальна: KVM и VMware ESXi показывают близкие результаты бенчмарков. А оптимизации вроде vStack с 2% overhead вообще делают накладные расходы незаметными. GPU-виртуализация – здесь VMware имела преимущество (технология vGPU), но сейчас SpaceVM и другие сократили отставание своим FreeGRID. Зато VMware до последнего времени обеспечивала более широкую поддержку оборудования (драйверы для любых RAID, сетевых карт) – российские ОС и гипервизоры поддерживают далеко не все модели железа, особенно новейшие. Однако ситуация улучшается за счет локализации драйверов и использования стандартных интерфейсов (VirtIO, NVMe и пр.).

Совместимость и экосистема

Ключевое различие – в экосистеме смежных решений. Окружение VMware – это огромный пласт интеграций: сотни backup-продуктов, мониторингов, готовых виртуальных апплаенсов, специальных плагинов и т.д. В российской экосистеме такого разнообразия пока нет. Многие специализированные плагины и appliance, рассчитанные на VMware, не будут работать на отечественных платформах.

Например, виртуальные апплаенсы от зарубежных вендоров (сетевые экраны, балансировщики), выпускались в OVF под vSphere – их можно включить и под KVM, но официальной поддержки может не быть. Приходится либо искать аналогичный российский софт, либо убеждаться, что в open-source есть совместимый образ. Интеграция с enterprise-системами – тоже вопрос: у VMware был vCenter API, поддерживаемый многими инструментами. Отечественным гипервизорам приходится писать собственные модули интеграции. Например, не все мониторинговые системы «из коробки» знают про zVirt или SpaceVM – нужно настраивать SNMP/API вручную.

Такая же ситуация с резервным копированием: знакомые всем Veeam и Veritas пока не имеют официальных агентов под наши платформы (хотя Veeam частично работает через стандартный SSH/VIX). В итоге на текущем этапе экосистема поддержки у VMware гораздо более развита, и это объективный минус для новых продуктов. Однако постепенно вокруг популярных российских гипервизоров формируется своё сообщество: появляются модули для Zabbix, адаптеры для Veeam через скрипты, свои решения backup (например, CyberProtect для Cyber Infrastructure, модуль бэкапа в VMmanager и т.п.).

Надёжность и поддержка

VMware десятилетиями оттачивала стабильность: vSphere известна редкими «падениями» и чётким поведением в любых ситуациях. Российским платформам пока ещё не хватает шлифовки – пользователи отмечают, что полностью «скучной» работу с ними назвать нельзя. Периодически инженерам приходится разбираться с нетривиальными багами или особенностями. В пример приводят трудоёмкость настройки сетевой агрегации (линков) – то, что на VMware привычно, на некоторых отечественных системах реализовано иначе и требует дополнительных манипуляций.

При обновлении версий возможны проблемы с обратной совместимостью: участники рынка жалуются, что выход каждого нового релиза иногда «ломает» интеграции, требуя доработки скриптов и настроек. Отсюда повышенные требования к квалификации админов – нужно глубже понимать «под капотом», чем при работе с отлаженной VMware. Но есть и плюс: почти все российские вендоры предоставляют оперативную техподдержку, зачастую напрямую от команд разработчиков. В критических случаях они готовы выпустить патч под конкретного заказчика или дать обходной совет. В VMware же, особенно после перехода на Broadcom, поддержка стала менее клиентоориентированной для средних клиентов. В России же каждый клиент на вес золота, поэтому реакция, как правило, быстрая (хотя, конечно, уровень экспертизы разных команд разнится).

Стоимость и лицензирование

Ранее VMware имела понятную, хоть и недешёвую модель лицензирования (по процессорам, +опции за функции). После покупки Broadcom стоимость выросла в разы, а бессрочные лицензии отменены – только подписка. Это сделало VMware финансово тяжелее для многих. Отечественные же продукты зачастую предлагают более гибкие условия: кто-то лицензирует по ядрам, кто-то по узлам, у кого-то подписка с поддержкой. Но в целом ценовой порог для легального использования ниже, чем у VMware (тем более, что последняя официально недоступна, а «серыми» схемами пользоваться рискованно). Некоторые российские решения и вовсе доступны в рамках господдержки по льготным программам для госучреждений. Таким образом, с точки зрения совокупной стоимости владения (TCO) переход на отечественную виртуализацию может быть выгоден (но может и не быть), особенно с учётом локальной техподдержки и отсутствия валютных рисков.

Подведём коротко плюсы и минусы российских платформ относительно VMware.

Плюсы отечественных решений:

• Импортонезависимость и соответствие требованиям. Полное соблюдение требований законодательства РФ для госкомпаний и КИИ (реестр ПО, совместимость с ГОСТ, сертификация ФСТЭК у компонентов).
• Локальная поддержка и доработка. Возможность напрямую взаимодействовать с разработчиком, получать кастомные улучшения под свои задачи и быстро исправлять проблемы в сотрудничестве (что практически невозможно с глобальным вендором).
• Интеграция с отечественной экосистемой. Совместимость с российскими ОС (Astra, РЕД, ROSA), СУБД, средствами защиты (например, vGate) – упрощает внедрение единого импортозамещённого ландшафта.
• Новые технологии под свои нужды. Реализация специфичных возможностей: работа без лицензий NVIDIA (FreeGRID), поддержка гостевых Windows без обращения к зарубежным серверам активации, отсутствие жёсткого вендорлока по железу (любое x86 подходит).
• Стоимость и модель владения. Более низкая цена лицензий и поддержки по сравнению с VMware (особенно после удорожания VMware); оплата в рублях, отсутствие риска отключения при санкциях.

Минусы и вызовы:

• Меньшая зрелость и удобство. Интерфейсы и процессы менее отточены – администрирование требует больше времени и знаний, некоторые задачи реализованы не так элегантно, больше ручной работы.
• Ограниченная экосистема. Не все привычные внешние инструменты совместимы – придется пересматривать решения для бэкапа, мониторинга, а автоматизация требует дополнительных скриптов. Нет огромного сообщества интеграторов по всему миру, как у VMware.
• Риски масштабируемости и багов. На больших нагрузках или в сложных сценариях могут всплывать проблемы, которые VMware уже давно решила. Требуется тщательное пилотирование и возможно компромиссы (уменьшить размер кластера, разделить на несколько и др.).
• Обучение персонала. ИТ-специалистам, годами работавшим с VMware, нужно переучиваться. Нюансы каждой платформы свои, документация не всегда идеальна, на русском языке материалов меньше, чем англоязычных по VMware.
• Отсутствие некоторых enterprise-фишек. Например, у VMware есть многолетние наработки по гибридному облаку, экосистема готовых решений в VMware Marketplace. Российским аналогам предстоит путь создания таких же богатых экосистем.

Таким образом, при функциональном паритете с VMware на бумаге, в практической эксплуатации российские продукты могут требовать больше усилий и доставлять больше проблем. Но этот разрыв постепенно сокращается по мере их развития и накопления опыта внедрений.

Выводы и перспективы импортозамещения VMware

За почти четыре года, прошедшие с ухода VMware, российская индустрия виртуализации совершила огромный рывок. Из десятков появившихся решений постепенно выделился костяк наиболее зрелых и универсальных продуктов, способных заменить VMware vSphere в корпоративных ИТ-инфраструктурах. Как показывают кейсы крупных организаций (банков, промышленных предприятий, госструктур), импортозамещение виртуализации в России – задача выполнимая, хотя и сопряжена с определёнными трудностями. Подводя итоги обзора, можно назвать наиболее перспективные платформы и технологии, на которые сегодня стоит обратить внимание ИТ-директорам:

• SpaceVM + Space VDI (экоcистема Space) – комплексное решение от компании «ДАКОМ M», которое отличается максимальной полнотой функционала. SpaceVM обеспечивает производительную серверную виртуализацию с собственными технологиями (SDN, FreeGRID), а Space VDI дополняет её средствами виртуализации рабочих мест. Этот тандем особенно хорош для компаний, которым нужны все компоненты "как у VMware" под одним брендом – гипервизор, диспетчеры, клиенты, протоколы. Space активно набирает популярность: 1-е место в рейтингах, успешные внедрения, награды отрасли. Можно ожидать, что он станет одним из столпов корпоративной виртуализации РФ.
• Basis Dynamix – продукт компании «Базис», ставший лидером технических рейтингов. Basis привлекает госзаказчиков и большие корпорации, ценящие интегрированный подход: платформа тесно сопряжена с отечественным оборудованием, ОС и имеет собственный центр разработки. Ее козыри – высокая производительность, гибкость (поддержка и классической, и HCI-схем) и готовность к кастомизации под клиента. Basis – хороший выбор для тех, кто строит полностью отечественный программно-аппаратный комплекс, и кому нужна платформа с длительной перспективой развития в России.
• zVirt (Orion soft) – одна из самых распространённых на практике платформ, обладающая богатым набором функций и сильным акцентом на безопасность. За счет происхождения от oVirt, zVirt знаком многим по архитектуре, а доработки Orion soft сделали его удобнее и безопаснее (SDN, микросегментация, интеграция с vGate). Крупнейшая инсталляционная база говорит о доверии рынка. Хотя у zVirt есть ограничения по масштабированию, для средних размеров (десятки узлов) он отлично справляется. Это надежный вариант для постепенной миграции с VMware в тех организациях, где ценят проверенные решения и требуются сертификаты ФСТЭК по безопасности.
• Red Виртуализация – решение от РЕД СОФТ, важное для госсектора и компаний с экосистемой РЕД ОС. Его выбрал, к примеру, Россельхозбанк для одной из крупнейших миграций в финансовом секторе. Продукт относительно консервативный (форк известного проекта), что можно считать плюсом – меньше сюрпризов, более понятный функционал. Red Virtualization перспективна там, где нужна максимальная совместимость с отечественным ПО (ПО РЕД, СУБД РЕД и пр.) и официальная поддержка на уровне регуляторов.
• vStack HCP – хотя и более нишевое решение, но весьма перспективное для тех, кому нужна простота HCI и высочайшая производительность. Отсутствие зависимости от громоздких компонентов (ни Linux, ни Windows – гипервизор на FreeBSD) дает vStack определенные преимущества в легковесности. Его стоит рассматривать в том числе для задач на периферии, в распределенных офисах, где нужна автономная работа без сложной поддержки, или для быстрорастущих облачных сервисов, где горизонтальное масштабирование – ключевой фактор.
• HostVM VDI / Veil / Termidesk – в сфере VDI помимо Space VDI, внимания заслуживают и другие разработки. HostVM VDI – как универсальный брокер с множеством протоколов – может подойти интеграторам, строящим сервис VDI для разных платформ. Veil VDI и Termidesk – пока чуть менее известны на рынке, но имеют интересные технологии (например, Termidesk с собственным кодеком TERA). Для компаний, уже использующих решения этих вендоров, логично присмотреться к их VDI для совместимости.

В заключение, можно уверенно сказать: российские продукты виртуализации достигли уровня, при котором ими можно заменить VMware vSphere во многих сценариях. Да, переход потребует усилий – от тестирования до обучения персонала, – но выгоды в виде независимости от внешних факторов, соответствия требованиям законодательства и поддержки со стороны локальных вендоров зачастую перевешивают временные сложности. Российские разработчики продемонстрировали способность быстро закрыть функциональные пробелы и даже внедрить новые инновации под нужды рынка. В ближайшие годы можно ожидать дальнейшего роста качества этих продуктов: уже сейчас виртуализация перестает быть "экзотикой" и становится обыденным, надёжным инструментом в руках отечественных ИТ-специалистов. А значит, корпоративный сектор России получает реальную альтернативу VMware – собственный технологический базис для развития ИТ-инфраструктуры.

Переход на VMware Cloud Foundation (VCF) 9 — это не просто обновление версии платформы. Он включает ребрендинг ключевых сервисов, перенос функций между компонентами, а также существенные улучшения управления жизненным циклом (Lifecycle Management). Для команд, планирующих миграцию с VCF 5.x, важно понимать, что именно изменилось: какие элементы остались прежними, какие переименованы, а какие были полностью заменены.

Об этом в общих чертах мы писали в прошлой статье, а сегодня разберём переход с VCF 5.x серии на версию VCF 9 через призму:

• Сравнения ключевых компонентов
• Архитектурных изменений
• Обновлений управления жизненным циклом
• Замены компонентов и блоков функционала

Обо всем этом рассказывается в видео ниже:

Базовая архитектура управления: что осталось неизменным

SDDC Manager — ядро VCF остаётся тем же

Один из наиболее важных выводов: SDDC Manager по-прежнему остаётся центральным движком управления VCF, и он:

• Присутствует как в VCF 5, так и в VCF 9
• Не меняет название (нет ребрендинга)
• Остаётся основным интерфейсом управления инфраструктурой

Однако отмечается, что в VCF 9 функциональность SDDC Manager расширена и улучшена по сравнению с 5-й серией.
Это важно, потому что SDDC Manager — "точка сборки" всей архитектуры VCF: он стабильный и развивается, миграции проще планировать и стандартизировать.

Изменения бренда и унификация: Aria -> VCF Operations

Одно из наиболее заметных изменений VCF 9 — это масштабный ребрендинг линейки VMware Aria в сторону единого зонтичного бренда VCF Operations.

VMware Aria Operations -> VCF Operations

Ранее компонент VMware Aria Operations выполнял роль:

• Централизованных дашбордов
• Мониторинга инфраструктуры
• Уведомлений и alerting
• SNMP-настроек
• Кастомной отчётности (например, oversizing виртуальных машин)
• Capacity planning

В VCF 9 этот же компонент переименован как часть стратегии VMware по движению к унифицированной "operations-платформе" в рамках VCF. Функционально компонент выполняет те же задачи, но позиционирование стало единым для всей платформы.

Operations-экосистема: логирование и сетевые инсайты

Aria Operations for Logs -> VCF Operations for Logs

Компонент логирования в VCF 5 назывался по-разному в средах заказчиков: Aria Operations for Logs и Log Insight. По сути — это централизованный syslog-агрегатор и анализатор, собирающий логи от всех компонентов VCF. В VCF 9 Aria Operations for Logs переименован VCF Operations for Logs. Функционально это тот же концепт, сбор логов остаётся централизованным и управляется как часть единого "Operations-стека".

Aria Operations for Network Insights -> VCF Operations for Network

Сетевой компонент прошёл длинный путь переименований: vRealize Network Insight, затем Aria Operations for Networks и, наконец, в VCF 9 он называется VCF Operations for Network.

Он обеспечивает:

• Централизованный мониторинг сети
• Диагностику
• Анализ сетевого трафика
• Возможности packet capture от источника до назначения

Главное архитектурное изменение: Lifecycle Management -> Fleet Management

VMware Aria Lifecycle Management (Aria LCM) -> VCF Operations Fleet Management

В VCF 5 жизненным циклом (апдейты/апгрейды) занимался компонент Aria Lifecycle Management (LCM), В VCF 9 сделан важный шаг - появился компонент VCF Operations Fleet Management. Это не просто переименование - продукт получил улучшенную функциональность, управление обновлениями и версиями стало более "streamlined", то есть рациональным и оптимизированным, а также появился акцент на fleet-подход: управление инфраструктурой как "парком платформ".

Fleet Management способен управлять несколькими инстансами VCF, что становится особенно важным для крупных организаций и распределённых инфраструктур. Именно тут виден "архитектурный сдвиг": VCF 9 проектируется не только как платформа для одного частного облака, а как унифицированная экосистема для гибридных и мультиинстанс-сценариев.

Feature transition: замена Workspace ONE Access

Workspace ONE Access удалён -> VCF Identity Broker

Одно из самых "жёстких" изменений — это не ребрендинг, а полная замена компонента. Workspace ONE Access полностью удалён (removed), вместо него введён новый компонент VCF Identity Broker. Это новый компонент для управления идентификацией (identity management), интеграции доступа, IAM-сценариев (identity access management), интеграции авторизации/аутентификации для экосистемы VCF.

Миграция и перемещение рабочих нагрузок: HCX теперь - часть Operations

VMware HCX -> VCF Operations HCX

HCX остаётся инструментом для пакетной миграции виртуальных машин (bulk migration) и миграций из одной локации в другую (в т.ч. удалённые площадки). Но в VCF 9 меняется позиционирование продукта: он теперь полностью интегрирован в VCF Operations и называется VCF Operations HCX. То есть HCX становится частью единого "операционного" контура VCF 9.

Автоматизация: упрощение названий и интеграция компонентов

Aria Automation -> VCF Automation

Это компонент автоматизации, отвечающий за сценарии и рабочие процессы частного облака, развертывание рабочих нагрузок и ежедневные операции. В VCF 9 это просто VCF Automation.

Aria Automation Orchestrator -> VCF Operations Orchestrator

Orchestrator используется для end-to-end рабочих процессов и автоматизации процессов создания ВМ и операций. В VCF 9 это теперь просто VCF Operations Orchestrator. Это важно: Orchestrator закрепляется как часть "operations-логики", а не просто автономный компонент автоматизации.

VMware Cloud Director: интеграция/поглощение в VCF Automation

Теперь VMware Cloud Director имеет новое позиционирование: продукт полностью интегрирован в VCF Automation. То есть Cloud Director как самостоятельное наименование уходит на второй план, а функции “переезжают” или связываются с модулем VCF Automation.

Слой Kubernetes: vSphere with Tanzu -> vSphere Supervisor

vSphere with Tanzu переименован в vSphere Supervisor

Это важное изменение, отражающее стратегию VCF по треку modern apps. Supervisor рассматривается как компонент для приложений новой волны, перехода monolith > microservices, контейнерного слоя и инфраструктуры enterprise-grade Kubernetes.

Платформа VCF при этом описывается как:

• Unified Cloud Platform
• Подходит для частного облака
• Интегрируется с hyperscalers (AWS, Azure, Google Cloud и т.д.)
• Поддерживает enterprise Kubernetes services

Итоги: что означает переход VCF 5 -> VCF 9 для архитектуры и миграции

Переход от VCF 5.x к VCF 9 — это комбинация трёх больших тенденций:

1) Унификация бренда и операционной модели

Aria-компоненты массово становятся частью семейства VCF Operations.

2) Улучшение управления жизненным циклом

LCM эволюционирует в Fleet Management, что отражает переход к управлению группами платформ и множественными VCF-инстансами.

Самое заметное — удаление Workspace ONE Access и введение VCF Identity Broker.

Cоответствие компонентов VCF 5.x и VCF 9

• SDDC Manager -> SDDC Manager (улучшен)
• Aria Operations -> VCF Operations
• Aria Operations for Logs -> VCF Operations for Logs
• Aria Operations for Network Insights -> VCF Operations for Network
• Aria LCM -> VCF Operations Fleet Management
• Workspace ONE Access -> VCF Identity Broker (замена продукта)
• HCX -> VCF Operations HCX
• Aria Automation -> VCF Automation
• Aria Automation Orchestrator -> VCF Operations Orchestrator
• Cloud Director -> интеграция в VCF Automation
• vSphere with Tanzu -> vSphere Supervisor

В новом видео на канале Gnan Cloud Garage подробно разобраны ключевые отличия между VMware Cloud Foundation (VCF) версии 5.2 и VCF 9.0, причем автор подчеркивает: речь идёт не о простом обновлении, а о кардинальной архитектурной переработке платформы.

VCF — это флагманская платформа частного облака от компании VMware, объединяющая вычисления, сеть, хранилище, безопасность, автоматизацию и управление жизненным циклом в едином программно-определяемом стеке. В версии 9.0 VMware делает шаг в сторону «облачного» подхода, ориентированного на масштаб, автоматизацию и гибкость.

Основные отличия VCF 5.2 и VCF 9.0

1. Модель развертывания

• VCF 5.2: установка строилась вокруг SDDC Manager и требовала загрузки Cloud Builder размером около 20 ГБ. Развёртывание компонентов происходило последовательно.
• VCF 9.0: представлен новый VCF Installer (~2 ГБ) и fleet-based модель. Это обеспечивает более быстрое развертывание, модульную архитектуру и гибкость с первого дня.

Результат: ускорение внедрения и переход от монолитного подхода к модульному.

2. Управление жизненным циклом (LCM)

• VCF 5.2: весь LCM был сосредоточен в SDDC Manager.
• VCF 9.0: управление разделено между Fleet Management Appliance и SDDC Manager.
  
  
• Fleet Management отвечает за операции, автоматизацию и управление идентификацией.
• SDDC Manager фокусируется на базовой инфраструктуре.

Результат: параллельные обновления, меньшее время простоя и более точный контроль.

3. Управление идентификацией

• VCF 5.2: использовались Enhanced Linked Mode и vCenter Identity.
• VCF 9.0: внедрены VCF Single Sign-On и VCF Identity Broker, обеспечивающие единую систему идентификации для всех компонентов.

Результат: действительно унифицированная и современная модель identity management.

4. Лицензирование

• VCF 5.2: традиционные лицензии — по продуктам и ключам (vSphere, NSX, vSAN, Aria).
• VCF 9.0: keyless subscription model — без ключей, с подпиской.

Результат: упрощённое соответствие требованиям, обновления и соответствие современным облачным моделям потребления.

5. Операции и мониторинг

• VCF 5.2: VMware Aria Operations — опциональный компонент.
• VCF 9.0: операции встроены по умолчанию, обеспечивая fleet-wide мониторинг и compliance «из коробки».

6. Автоматизация

• VCF 5.2: автоматизация была дополнительной опцией.
• VCF 9.0: решение VCF Automation встроено и оптимизировано для:

• AI-нагрузок
• Kubernetes
• виртуальных машин

Результат: платформа самообслуживания, полностью готовая для разработчиков.

• VCF 5.2: NSX — опциональный компонент.
• VCF 9.0: NSX становится обязательным для management и workload-доменов.

Результат: единая программно-определяемая сетевая архитектура во всей среде VCF.

8. Хранилище

• VCF 5.2: поддержка vSAN, NFS и Fibre Channel SAN.
• VCF 9.0: акцент на vSAN ESA (Express Storage Architecture) и Original Storage Architecture, с планами по расширению поддержки внешних хранилищ.

Результат: фундамент для более современной и производительной storage-архитектуры.

9. Безопасность и соответствие требованиям

• VCF 5.2: ручное управление сертификатами и патчами.
• VCF 9.0: встроенные средства управления:
  
  
  • унифицированное управление ключами
  • live patching
  • secure-by-default подход

Результат: серьёзная модернизация безопасности и Zero Trust по умолчанию.

10. Модель обновлений

• VCF 5.2: последовательные апгрейды.
• VCF 9.0: параллельные обновления с учётом fleet-aware LCM.

Результат: меньше простоев и лучшая предсказуемость обслуживания.

11. Kubernetes и контейнеры

• VCF 5.2: ограниченная поддержка Tanzu.
• VCF 9.0: нативный Kubernetes через VCF Automation.

Результат: единая платформа для VM и Kubernetes — полноценная application platform.

12. Импорт существующих сред

• VCF 5.2: импорт существующих vSphere/vCenter не поддерживался.
• VCF 9.0: можно импортировать существующие окружения как management или workload-домены.

Результат: упрощённая миграция legacy-нагрузок в современное частное облако.

Итог

VCF 5.2 — это классическая платформа частного облака с опциональными возможностями, ну а VCF 9.0 — это современное, cloud-like частное и гибридное облако, ориентированное на масштабирование, автоматизацию и управление флотом инфраструктуры.

Как подчёркивает автор видео, VCF 9.0 — это не апгрейд, а полноценный редизайн, нацеленный на лучший пользовательский опыт и соответствие требованиям современных enterprise и облачных сред.

В этой части статьи мы продолжаем рассказывать об итогах 2025 года в плане серверной и настольной виртуализации на базе российских решений. Первую часть статьи можно прочитать тут.

Возможности VDI (виртуализации рабочих мест)

Импортозамещение коснулось не только серверной виртуализации, но и инфраструктуры виртуальных рабочих столов (VDI). После ухода VMware Horizon (сейчас это решение Omnissa) и Citrix XenDesktop российские компании начали внедрять отечественные VDI-решения для обеспечения удалённой работы сотрудников и центрального управления рабочими станциями. К 2025 году сформировался пул новых продуктов, позволяющих развернуть полнофункциональную VDI-платформу на базе отечественных технологий.

Лидерами рынка VDI стали решения, созданные в тесной связке с платформами серверной виртуализации. Так, компания «ДАКОМ М» (бренд Space) помимо гипервизора SpaceVM предложила продукт Space VDI – систему управления виртуальными рабочими столами, интегрированную в их экосистему. Space VDI заняла 1-е место в рейтинге российских VDI-решений 2025 г., набрав 228 баллов по совокупности критериев.

Её сильные стороны – полностью собственная разработка брокера и агентов (не опирающаяся на чужие open-source) и наличие всех компонентов, аналогичных VMware Horizon: Space Dispatcher (диспетчер VDI, альтернатива Horizon Connection Server), Space Agent VDI (клиентский агент на виртуальной машине, аналог VMware Horizon Agent), Space Client для подключения с пользовательских устройств, и собственный протокол удалённых рабочих столов GLINT. Протокол GLINT разработан как замена зарубежных (RDP/PCoIP), оптимизирован для работы в российских сетях и обеспечивает сжатие/шифрование трафика. В частности, заявляется поддержка мультимедиа-ускорения и USB-перенаправления через модуль Mediapipe, который служит аналогом Citrix HDX. В результате Space VDI предоставляет высокую производительность графического интерфейса и мультимедиа, сравнимую с мировыми аналогами, при этом полностью вписывается в отечественный контур безопасности.

Вторым крупным игроком стала компания HOSTVM с продуктом HostVM VDI. Этот продукт изначально основыван на открытой платформе UDS (VirtualCable) и веб-интерфейсе на Angular, но адаптирован российским разработчиком. HostVM VDI поддерживает широкий набор протоколов – SPICE, RDP, VNC, NX, PCoIP, X2Go, HTML5 – фактически покрывая все популярные способы удалённого доступа. Такая всеядность упрощает миграцию с иностранных систем: например, если ранее использовался протокол PCoIP (как в VMware Horizon), HostVM VDI тоже его поддерживает. Решение заняло 2-е место в отраслевом рейтинге с 218 баллами, немного уступив Space VDI по глубине интеграции функций.

Своеобразный подход продемонстрировал РЕД СОФТ. Их продукт «РЕД Виртуализация» является, в первую очередь, серверной платформой (форком oVirt на KVM) для развертывания ВМ. Однако благодаря тесной интеграции с РЕД ОС и другим ПО компании, Red Виртуализация может использоваться и для VDI-сценариев. Она заняла 3-е место в рейтинге VDI-платформ. По сути, РЕД предлагает создать инфраструктуру на базе своего гипервизора и доставлять пользователям рабочие столы через стандартные протоколы (для Windows-ВМ – RDP, для Linux – SPICE или VNC). В частности, поддерживаются протоколы VNC, SPICE и RDP, что покрывает базовые потребности. Кроме того, заявлена возможность миграции виртуальных машин в РЕД Виртуализацию прямо из сред VMware vSphere и Microsoft Hyper-V, что упрощает переход на решение.

Далее, существуют специализированные отечественные VDI-продукты: ROSA VDI, Veil VDI, Termidesk и др.

• ROSA VDI (разработка НТЦ ИТ РОСА) базируется на том же oVirt и ориентирована на интеграцию с российскими ОС РОСА.
• Veil VDI – решение компаний «НИИ Масштаб»/Uveon – представляет собственную разработку брокера виртуальных рабочих столов; оно также попало в топ-5 рейтинга.
• Termidesk – ещё одна проприетарная система, замыкающая первую шестёрку лидеров. Каждая из них предлагает конкурентоспособные функции, хотя по некоторым пунктам уступает лидерам. Например, Veil VDI и Termidesk пока набрали меньше баллов (182 и 174 соответственно) и, вероятно, имеют более узкую специализацию или меньшую базу внедрений.
  

Общей чертой российских VDI-платформ является ориентация на безопасность и импортозамещение. Все они зарегистрированы как отечественное ПО и могут применяться вместо VMware Horizon, Citrix или Microsoft RDS. С точки зрения пользовательского опыта, основные функции реализованы: пользователи могут подключаться к своим виртуальным рабочим столам с любых устройств (ПК, тонкие клиенты, планшеты) через удобные клиенты или даже браузер. Администраторы получают централизованную консоль для создания образов ВМ, массового обновления ПО на виртуальных рабочих столах и мониторинга активности пользователей. Многие решения интегрируются с инфраструктурой виртуализации серверов – например, Space VDI напрямую работает поверх гипервизора SpaceVM, ROSA VDI – поверх ROSA Virtualization, что упрощает установку.

Отдельно стоит отметить поддержку мультимедийных протоколов и оптимизацию трафика. Поскольку качество работы VDI сильно зависит от протокола передачи картинки, разработчики добавляют собственные улучшения. Мы уже упомянули GLINT (Space) и широкий набор протоколов в HostVM. Также используется протокол Loudplay – это отечественная разработка в области облачного гейминга, адаптированная под VDI.

Некоторые платформы (например, Space VDI, ROSA VDI, Termidesk) заявляют поддержку Loudplay наряду со SPICE/RDP, чтобы обеспечить плавную передачу видео и 3D-графики даже в сетях с высокой задержкой. Терминальные протоколы оптимизированы под российские условия: так, Termidesk применяет собственный кодек TERA для сжатия видео и звука. В результате пользователи могут комфортно работать с графическими приложениями, CAD-системами и видео в своих виртуальных десктопах.

С точки зрения масштабируемости VDI, российские решения способны обслуживать от десятков до нескольких тысяч одновременных пользователей. Лабораторные испытания показывают, что Space VDI и HostVM VDI могут управлять тысячами виртуальных рабочих столов в распределенной инфраструктуре (с добавлением необходимых серверных мощностей). Важным моментом остаётся интеграция со средствами обеспечения безопасности: многие платформы поддерживают подключение СЗИ для контроля за пользователями (DLP-системы, антивирусы на виртуальных рабочих местах) и могут работать в замкнутых контурах без доступа в интернет.

Таким образом, к концу 2025 года отечественные VDI-платформы покрывают основные потребности удалённой работы. Они позволяют централизованно развертывать и обновлять рабочие места, сохранять данные в защищённом контуре датацентра и предоставлять сотрудникам доступ к нужным приложениям из любой точки. При этом особый акцент сделан на совместимость с российским стеком (ОС, ПО, требования регуляторов) и на возможность миграции с западных систем с минимальными затратами (поддержка разных протоколов, перенос ВМ из VMware/Hyper-V). Конечно, каждой организации предстоит выбрать оптимальный продукт под свои задачи – лидеры рынка (Space VDI, HostVM, Red/ROSA) уже имеют успешные внедрения, тогда как нишевые решения могут подойти под специальные сценарии.

Кластеризация, отказоустойчивость и управление ресурсами

Функциональность, связанная с обеспечением высокой доступности (HA) и отказоустойчивости, а также удобством управления ресурсами, является критичной при сравнении платформ виртуализации. Рассмотрим, как обстоят дела с этими возможностями у российских продуктов по сравнению с VMware vSphere.

Кластеризация и высокая доступность (HA)

Почти все отечественные системы поддерживают объединение хостов в кластеры и автоматический перезапуск ВМ на доступных узлах в случае сбоя одного из серверов – аналог функции VMware HA. Например, SpaceVM имеет встроенную поддержку High Availability для кластеров: при падении хоста его виртуальные машины автоматически запускаются на других узлах кластера.

Basis Dynamix, VMmanager, Red Virtualization – все они также включают механизмы мониторинга узлов и перезапуска ВМ при отказе, что отражено в их спецификациях (наличие HA подтверждалось анкетами рейтингов). По сути, обеспечение базовой отказоустойчивости сейчас является стандартной функцией для любых платформ виртуализации. Важно отметить, что для корректной работы HA требуется резерв мощности в кластере (чтобы были свободные ресурсы для поднятия упавших нагрузок), поэтому администраторы должны планировать кластеры с некоторым запасом хостов, аналогично VMware.

Fault Tolerance (FT)

Более продвинутый режим отказоустойчивости – Fault Tolerance, при котором одна ВМ дублируется на другом хосте в режиме реального времени (две копии работают синхронно, и при сбое одной – вторая продолжает работать без прерывания сервиса). В VMware FT реализован для критичных нагрузок, но накладывает ограничения (например, количество vCPU). В российских решениях прямая аналогия FT практически не встречается. Тем не менее, некоторые разработчики заявляют поддержку подобных механизмов. В частности, Basis Dynamix Enterprise в материалах указывал наличие функции Fault Tolerance. Однако широкого распространения FT не получила – эта технология сложна в реализации, а также требовательна к каналам связи. Обычно достаточен более простой подход (HA с быстрым перезапуском, кластерные приложения на уровне ОС и т.п.). В критических сценариях (банковские системы реального времени и др.) могут быть построены решения с FT на базе метрокластеров, но это скорее штучные проекты.

Снапшоты и резервное копирование

Снимки состояния ВМ (snapshots) – необходимая функция для безопасных изменений и откатов. Все современные платформы (zVirt, SpaceVM, Red и прочие) поддерживают создание мгновенных снапшотов ВМ в рабочем состоянии. Как правило, доступны возможности делать цепочки снимков, однако требования к хранению диктуют, что постоянно держать много снапшотов нежелательно (как и в VMware, где они влияют на производительность). Для резервного копирования обычно предлагается интеграция с внешними системами бэкапа либо встроенные средства экспорта ВМ.

Например, SpaceVM имеет встроенное резервное копирование ВМ с возможностью сохранения бэкапов на удалённое хранилище. VMmanager от ISPsystem также предоставляет модуль бэкапа. Тем не менее, организации часто используют сторонние системы резервирования – здесь важно, что у российских гипервизоров обычно открыт API для интеграции. Почти все продукты предоставляют REST API или SDK, позволяющий автоматизировать задачи бэкапа, мониторинга и пр. Отдельные вендоры (например, Basis) декларируют принцип API-first, что упрощает связку с оркестраторами резервного копирования и мониторинга.

Управление ресурсами и балансировка

Мы уже упоминали наличие аналогов DRS в некоторых платформах (автоматическое перераспределение ВМ). Кроме этого, важно, как реализовано ручное управление ресурсами: пулы CPU/памяти, приоритеты, квоты. В VMware vSphere есть ресурсные пулы и shares-приоритеты. В российских системах подобные механизмы тоже появляются. zVirt, например, позволяет объединять хосты в логические группы и задавать политику размещения ВМ, что помогает распределять нагрузку. Red Virtualization (oVirt) исторически поддерживает задание весов и ограничений на ЦП и ОЗУ для групп виртуальных машин. В Basis Dynamix управление ресурсами интегрировано с IaC-инструментами – можно через Terraform описывать необходимые ресурсы, а платформа сама их выделит.

Такое тесное сочетание с DevOps-подходами – одно из преимуществ новых продуктов: Basis и SpaceVM интегрируются с Ansible, Terraform для автоматического развертывания инфраструктуры как кода. Это позволяет компаниям гибко управлять ИТ-ресурсами и быстро масштабировать кластеры или развертывать новые ВМ по шаблонам.

Управление кластерами

Центральная консоль управления кластером – обязательный компонент. Аналог VMware vCenter в отечественных решениях присутствует везде, хотя может называться по-разному. Например, у Space – SpaceVM Controller (он же выполняет роль менеджера кластера, аналог vCenter). У zVirt – собственная веб-консоль, у Red Virtualization – знакомый интерфейс oVirt Engine, у VMmanager – веб-панель от ISPsystem. То есть любой выбранный продукт предоставляет единый интерфейс для управления всеми узлами, ВМ и ресурсами. Многие консоли русифицированы и достаточно дружелюбны. Однако по отзывам специалистов, удобство администрирования ещё требует улучшений: отмечается, что ряд операций в отечественных платформах более трудоёмкие или требуют «танцев с бубном» по сравнению с отлаженным UI VMware. Например, на Хабре приводился пример, что создание простой ВМ в некоторых системах превращается в квест с редактированием конфигурационных файлов и чтением документации, тогда как в VMware это несколько кликов мастера создания ВМ. Это как раз то направление, где нашим решениям ещё есть куда расти – UX и простота администрирования.

В плане кластеризации и отказоустойчивости можно заключить, что функционально российские платформы предоставляют почти весь минимально необходимый набор возможностей. Кластеры, миграция ВМ, HA, снапшоты, бэкап, распределенная сеть, интеграция со сториджами – всё это реализовано (см. сводную таблицу ниже). Тем не менее, зрелость реализации зачастую ниже: возможны нюансы при очень крупных масштабах, не все функции могут быть такими же «отполированными» как у VMware, а администрирование требует большей квалификации.

Продолжение следует...